Am Samstag 31 März 2001 14:24 schrieb Adam J. Richter:
> >> = Adam Richter
> >
> > = Oliver Neukum
> >
> >> I am currently interested in the USB user level drivers because
> >> I think it may be better to move all Human Input Device USB drivers
> >> to user land. The HID "report" descriptors are fairly complex, so
> >
> >No !
> >
> >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.
> >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.
> sort of thing you can "ssh in" to fix. If not, then you want to
Assuming that you have net connectivity on that machine, which is far from
given.
> have a ramdisk laying around with the daemon, which, unlike the
> kernel modules would not need to be rebuilt for each version of
> the kernel.
So you can no longer boot without an initrd ?
> >> would be more reassured in this feeling if I had some numbers on what
> >> kind of latency is needed for joysticks and the like in things like fast
> >> video games.
> >
> >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.
> 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.
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. Here goes another
kernel stack, etc. .You can't use a keyboard without usbdevfs, which must be
mounted.
Furthermore you'd have ruined any attempt to have a unified input layer. pty
handling is made harder. The more I think about it, the worse it gets.
In short, this is a very bad idea.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
