cvs-src summary for November 15-22

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