> 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.)
0.001% of an average HD.
> 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.
But they don't have to go through IPC.
> >> 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.
Plus the cache you dirty, which affects other tasks. And the TLB you flush.
> >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
Yes. For security you can't use a shared library, you need a demon.
That demon must be available quickly even under severe memory pressure.
Thus you need to run it with mlock(). Furthermore a task in contrast to a
kernel driver needs a kernel stack, an mlocked user level stack and page
tables.
Then user level code will be more complicated, because you need to do the
multithreading a kernel driver gets for free. Doing a microkernel is hard.
> >Here goes another kernel stack, etc.
>
> In comparison, kernel code is unswappable, and HID certainly has
> state of its own.
Not more than a demon. Or rather less because a demon has a harder job of
attaching devices to tasks. The kernel keeps track of the ownership of fds.
> >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.
The problem is that a keyboard is needed in emergency.
> >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.
Good question. Have you asked Vojtech ?
Hm... How do you make gpm work on consoles used directly by the kernel ?
> >pty handling is made harder. [...]
>
> Please explain.
Two cases. USB and not USB.
> 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
Why not give the descriptors not understood only to user space like in other
hotplug setups ?
> 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,
That would be a network console project, which is certainly worth doing, but
where is the connection ?
> 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
This is about to change in the relevant time.
> not need to have n copies of the code if you have n kernels, and you
> can update the code more easily.
Another package to get and update seperately. A kernel level HID is
recompiled like all other modules.
> 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.
Why handle HID differently from other hotplug devices ?
> 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
Do you want eventually or don't you want to ?
> 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.
Simply make available the raw descriptors which are not understood or are not
drivable by currently loaded modules. No additional demons and only a small
deviation from the other hotpluggable devices.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
