>>>> = Adam Richter
>>> = Oliver Neukum
>> = Adam Richter
> = Oliver Neukum
>>>> [...] move all Human Input Device USB drivers to user land. [...]
>>>At least keyboard has to remain in kernel, else no sysreq nor sak nor
>>>scrollback during boot.
>> That is already the situation when usbcore, the root hub driver
>> or the usb keyboard driver are loadable modules. However, I appreciate
>> your point and agree that it would assist debugging to retain the ability
>> to compile these things in.
>That is a (IMHO stupid) choice made at kernel compilation. The ability _must_
>be retained.
Let's stick to statements of object cause and effect rather
than words like "stupid" and "must." Intimidation language like the
above should lead readers to wonder if the author is using filler for
a lack of technical specifics and, if so, why.
I believe that most, perhaps all, Linux distributions that
ship with usb support ship it built as kernel modules, so your complaint
applies to all of those current distributions. Since I am not talking
about losing the _ability_ to compile in kernel USB keyboard support,
your concern is not more applicable to my scheme than it is to those
existing distributions.
>> >In addition it adds a lot of brittleness to require a
>> >demon running in single user mode, etc.
>>
>> You have to be careful, but this is less "brittleness"
>> than, say, shared libraries. If the system still boots, its the
>You can compile bash and init statically. A lot of people do so.
You can make a rescue floppy that includes either a kernel built
with USB keyboard support compiled in or that includes a copy of the
USB keyboard program. There are lots of files in a system that, if
corrupted, would require connecting over the network or botting from
rescue media or a rescue ramdisk image. Granted, compiling in usbcore,
your usb root hub driver, and usbkbd or usbhid would make the system
more robust, but I am not talking about preventing that, and the
differences that I care about are between the a ordinary-use "fully
modularized" kernel and doing HID at user level.
Some of your other comments are also addressed by the above
paragraph, so I have deleted them for the sake of brevity.
By the way, "Hello world" linked statically under glibc-2.2.2
is about 300kB, stripped.)
Regarding one of my original questions, regarding latency:
>> >Please think of things like forcefeedback.
>>
>> A force feedback joystick will likely involve round trips from
>> user land either way, unless you are proposing to embed something like
>> a terrain map in the kernel.
>They require one simple ioctl.
You are still going have to make a lot of those system calls
in real time. The user level program needs to think about it either
way.
>> What I am most interested in is _numbers_ rather than what one
>> might call "performance FUD." Any statistics on required latencies,
>> etc., would be very helpful.
>I have no info at hand, just one data point.
>The new input layer is reported to query a serial mouse at 48HZ.
>A USB mouse won't be slower. Thus you have 48 more task switches per second
>while moving the mouse.
Assuming you do an HID SET_IDLE(0) request to the mouse, a USB
mouse will report events only when an event occurs.
Anyhow, 48 iterations per second would be nothing. lmbench on my
866MHz P3 reports a pipe latency (that's a context switch) of 6.08
microseconds. (that's a context switch). 48Hz is 20,833
microseconds, or a factor of 1/3426th. Perhaps one a slower machine,
that might be as much as 1/500th of 48Hz.
>In addition you now require _more_ resources than the kernel driver. As the
>driver has to work in real time, you need to do an mlock.
I don't know what you mean here.
Given your previous suggestion about time stamps, it looks like
user level HID support
>Here goes another kernel stack, etc.
In comparison, kernel code is unswappable, and HID certainly has
state of its own.
>You can't use a keyboard without usbdevfs, which must be mounted.
Yes, I regard usbdevfs as required for everything except certain types
of highly customized embedded applicatoins or emergency situations.
In general, I find the complexity cost of supporting non-usbdevfs
operation is more than the complexity cost of usbdevfs itself.
>Furthermore you'd have ruined any attempt to have a unified input layer.
People are often tempted to add extra layers of abstraction into
an operating system's kernel. Having a uniform interface is reasonable,
but I have never understood why this layer should reside entirely in the
kernel rather than mostly as a user level abstraction, probably as a
library.
>pty handling is made harder. [...]
Please explain.
There is some complexity in having HID at user level, but I think
the benefits are worth that cost. User level code can use more elaborate
facilities and more easily doing things like maintain complex data
structures, access the filesystem, go over the network, recurse
through the most complex HID report desciptor without worry about
stack depth (albeit probably a pathalogical case anyhow), etc. It
would be much easier to implement things like a virtual keyboard and
mouse from an 802.11 wireless ethernet-based PDA, perhaps using pen
based writing recognition, or just to do simple remote control of
keyboard and mouse via the network. User level code is preemptable,
while kernel level code is only premtable at certain points, so
complex HID processing is less likely to interfere with realtime
demands, like, say, playing a video stream as part of a game. You do
not need to have n copies of the code if you have n kernels, and you
can update the code more easily.
I think a good place to start in terms of implemenation
might be to extend gpm to handle USB mice and keyboards on a hotplug
basis (i.e., some protocol for saying, "please add /proc/bus/usb/NN/NNN").
Then, it would be possible to do things like have a configuration file
that could define whether your USB touchpad should be merged into
the event stream of /dev/gpmmouse0 or should be a separate GPM mouse
device or should not be claimed by gpm, etc. It could also have
support for remote mouse and keyboard over the network (probably
ssh authenticated or something) that would be useful for, for example,
remote control via PDA.
Anyhow, I'm not arguing for removal of any kernel code before a better
system has been written in use for a while. The only action that I'm
trying to decide on is whether I should look at trying to develop a
scheme for kernel-centric HID hotplug support (with its own
MODULE_DEVICE_TABLE, etc.), which I currently think will result in a
very limiting system due to the complexity of HID ranging from
exercise bikes to uninterruptible power supplies , or think more about
implemenating a solution in user land, probably by stealing or writing
a user level library HID report descriptor parsing and generalizing
gpm.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
