Date: Tue, 23 Nov 2004 11:37:16 -0600 From: Mark Johnston <mjohnston@skyweb.ca> To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Subject: cvs-src summary for November 15-22 Message-ID: <200411231137.16215.mjohnston@skyweb.ca>
next in thread | raw e-mail | index | archive | help
FreeBSD cvs-src summary for 15/11/04 to 22/11/04 ++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. This newsletter is marked up in reStructuredText_, so any odd punctuation that you see is likely intended for the reST parser. .. _reStructuredText: http://docutils.sourceforge.net/rst.html You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). For Lukasz Dudek and Szymon Roczniak's Polish translations of these summaries, which may lag the English ones slightly, please see http://mocart.pinco.pl/FreeBSD/. .. contents:: ============ New features ============ MAC framework support added for System V IPC -------------------------------------------- Robert Watson (rwatson) committed support to the MAC (Mandatory Access Control) framework for System V IPC objects and operations. Most operations involving System V messages, message queues, semaphores, and shared memory segments can now be protected with MAC. For information and tutorials on FreeBSD's MAC layer, please see `chapter 15 of the Handbook`_. .. _`chapter 15 of the Handbook`: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html This code was submitted by Dandekar Hrishikesh, obtained from the TrustedBSD project, and sponsored by DARPA, SPAWAR, and McAfee Research. http://www.freebsd.org/cgi/mid.cgi?200411171310.iAHDAGBk066415 hme Ethernet driver now MPSAFE ------------------------------ Pyun YongHyeon (yongari) updated hme, the driver for many Sun Ethernet cards, to be MPSAFE. MPSAFE drivers can run without the Giant system lock, allowing better performance. http://www.freebsd.org/cgi/mid.cgi?200411220646.iAM6kVG7018054 =============== Notable changes =============== 386 support removed ------------------- John Baldwin (jhb) made changes to remove support for the 386 processor in FreeBSD 6-CURRENT. He eliminated 386-specific code from the kernel, run-time linker, C library, and system Makefiles. http://www.freebsd.org/cgi/mid.cgi?200411162042.iAGKgWrF095430 ================= Discussion topics ================= Keyboard technologies and drivers --------------------------------- Maksim Yevmenkin (emax) committed support for a virtual AT keyboard driver, called vkbd. Poul-Henning Kamp (phk) asked, "I thought we had one of those already ?" Maksim replied, "when? where? did i miss it?" Poul-Henning replied, "sys/dev/kbd (and various MD stuff all over the place) ?" Maksim responded, "perhaps i'm missing something here. the idea behind vkdb(4) is to create a keyboard [ . . . ] that accepts scan codes from userspace and not from real hardware. [ . . . ] what i want to do is to obtain scan codes from bluetooth keyboard and then feed them into the kernel. [ . . . ] i do not think i can do it with kdb(4), can i?" Brooks Davis (brooks) suggested, "Have you considered making the virtual keyboard an in kernel client of it's child keyboard(s)? If you don't do this, you can't use the virtual keyboard in single user mode or in the debugger." Maksim replied, "in case of bluetooth hid all scan codes have to passed through bluetooth stack. i definitely do not want to use bluetooth keyboard in ddb(4) or in single user mode :)" Brooks responded, "I'm primairly intrested in solving the problem of machines with a AT keyboard controller (which currently attached non-existant keyboards to allow hot-pluging) and a USB keyboard." M. Warner Losh (imp) responded, "I think emax's vkbd isn't the same as the 'many to one' keyboard mux driver that's been talked about to solve [that]." Maksim replied, "that is true, but... you \*could\* obtain scan codes from two or more sources and write them into the \*same\* vkbd. [ . . . ] the only problem is the vkbd state (shifts controls etc)." Philip Paeps (philip) also replied to Brooks's post about AT+USB machines, saying, "My idea would be to feed all 'input events' from hardware drivers into a pseudo-driver, serialize it, and send it on to the higher layers of the system." Brooks responded, "That's basicly what I would like to see. I don't think we need to support people hitting the accent key on one keyboard and then finishing typing on the other, but we do need to support multiple keyboards if only because the users expect it." Philip replied, "I'd like to assume that the fundamental 'event' from a keyboard to reach the console is going to be a 'character'. [ . . . ] Alt on kbd0 followed by 'a' on kbd1 should probably translate to just 'a'." He also noted, "If we're going to let people have multiple keyboards, there will be those who will want to have a US-qwerty and a Belgian azerty side-by-side. Mapping keys will probably need to be handled by the driver (or the input system) on a per-device basis rather than by the console driver. That little headache has been fermenting at the back of my head since I first started thinking about writing an input layer." Brooks replied, "From looking at the atkbd driver, I thought we were fairly character oriented[ . . . . ] The seperate keymap issue is one I hadn't thought of since I'm in US-ASCII land. ;-) It could actually make a fair bit of sense to hook keyboards up that way. On the other hand, getting the single keymap case working and doing it well would be a huge step in the right direction." Marcel Moolenaar (marcel) also replied, saying, "I'm no guru in this regard, but it's probably best to take it one step at a time." He then gave some suggestions for possible implementations. Scott Long (scottl) replied to Maksim's earlier post about the bluetooth stack, saying, "I appreciate the work here, but we are starting to grow too many independent keyboard abstractions that don't seem to work together and don't seem to solve the primary problem that we have right now. What we really need is a single unified keyboard and mouse virtualization layer that allows bluetooth, usb, and at/ps2 devices to plug in at the bottom and talk to the one or more console interfaces at the top. [ . . . ] And yt _does_ need to work in single user mode and in DDB. [ . . . ] Brooks had talked about working on something similar to what I've described above, so please work with him to mold your vkbd work into that model." Maksim responded, "i did sent email to current asking for comments. did not get much feedback." He replied to Scott's suggestion about Brooks's work, saying, "very well. i touched it. might as well try and fix it :) anyone has any ideas? code? anything? oh, one more thing, would you like me to back vkbd(4) out?" Scott replied, "If there is no chance that the BT device could be needed for DDB or single-user mode then I guess that your driver is a good thing, though the 'vkbd' name is a bit misleading since it really only applies to BT." Maksim replied, "bluetooth keyboard definitely not needed in ddb and single mode (imo). but vkbd is not bluetooth specific. you could write an application that will tunnel at scancodes over the network say." Marcel responded to this, saying, "I very strongly disagree with this [that bluetooth is not needed in ddb/single user]. In fact, it's this sentiment that created the PS/2 vs USB keyboard problem for which we need a mux. [ . . . ] I think it's a mistake to treat a PS/2 keyboard different from any other keyboard simply because the interface is primitive. [ . . . ] Other than that. I think vkbd(4) can stay. Between no support and partial or imperfect support, we might as well keep the imperfect support until we're done perfecting things." Warner replied, "If we make it so that vkbd is also useful from whthin the kernel, then we can use it to implement many different things. [ . . . ] If bluetooth keyboards do become common place, we'll have to move bluetooth into the kernel to support them in single user mode or in ddb." Warner also replied to Scott's post about vkbd being Bluetooth-specific, saying, "Having looked at the code, it looks like one could also use it to implment a newton keyboard interface as well." He explained that the Newton keyboard is a small, serially-attached keyboard used with tiny laptops. Brooks responded, "vkbd is probably actually a good place to start working on the mux. The decision to add the functionality to vkbd or to split it out to another driver is a separate issue and I can make it later." Philip replied to Scott's post about a unified virtualization layer, saying, "I sollicited ideas for a 'generic input core' layer on -arch not long ago :-) [ . . . ] My idea/dream/goal/foo is to have a little driver provide an interface to sit between [keyboard, mouse, and touchscreen drivers], and feed events back to syscons in a consistent sort of way." He talked a bit about an implementation that he has been working on. http://www.freebsd.org/cgi/mid.cgi?200411161659.iAGGxNiX087329 =================== Important bug fixes =================== Security vulnerability in fetch fixed ------------------------------------- Colin Percival (cperciva) committed a fix to fetch, which retrieves files via HTTP(S) and FTP. The fix corrects an integer overflow bug that could allow malicious HTTP servers to execute arbitrary code as the user running fetch. He also fixed the bug in 5-STABLE, 4-STABLE, and the security branches for 5.3, 5.2, 5.1, 5.0, 4.10, 4.9, 4.8, and 4.7. This bug was initially found and reported by Colin himself. A security advisory, `FreeBSD-SA-04:16.fetch`_, has been released. .. _`FreeBSD-SA-04:16.fetch`: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:16.fetch.asc http://www.freebsd.org/cgi/mid.cgi?200411181206.iAIC6qbX048177 =============== Other bug fixes =============== Tim J. Robbins (tjr) fixed a bug in the regular expression code within the system libraries that could cause hangs in UTF-8 (Unicode) locales. The bug was found and reported be Jean-Yves Lefort. http://www.freebsd.org/cgi/mid.cgi?200411210314.iAL3EWrN019655
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411231137.16215.mjohnston>