Oliver Neukum writes:
>> By the way, "Hello world" linked statically under glibc-2.2.2
>> is about 300kB, stripped.)
>0.001% of an average HD.
20% of an average floppy disk.
>> >> 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.
I made my original posting because I was asking about this IPC
cost. If you have more _numbers_, then please respond.
>> >> 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.
TLB switching is obviously part of that benchmark number.
cache dirtying is proportional to the amount of code executed, and
otherwise independent of whether a context switch was involved, or at
least I am 90% sure that data in both the L1 and L2 caches survives
across context switches (i.e., they are physical caches, not virtual
caches). Even in the worst case for some where, for some reason,
every fetch was a cache miss and kicked out useful data the reload
incurred by that useful data time would be no greater than the time
incurred by the code that kicked it out (well, modulo some page
locality if SDRAM drivers still benefit at all from same-page accesses),
and the miss rate will normally not be anywhere near 100% on the
small bit of additional code attributable to doing the context switch.
>> Given your previous suggestion about time stamps, it looks like
>> user level HID support
^^ Sorry for not finishing this setence. I think I meant
"...it looks like user level HID support would have no practical timing
problems."
>> >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.
>>
>Yes. For security you can't use a shared library, you need a demon.
Yes.
>That demon must be available quickly even under severe memory pressure.
Not that quickly, although it would be a nice administration
option. We don't mlock /bin/sh, for example, which is more necessary
for logging into a thrashing machine (since the keyboard driver is
only relevant if you are using the console rather than coming in from
the network or a serial line).
Rather than repeat myself, I have deleted your other comments
that were predicated on the idea that it is (rather than just repeat
myself).
>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.
Kernel and user level have different complexity costs for
different types of "multithreading." In the kernel, you have to
be more careful where you block, for example.
>> >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.
Then either usbdevfs is mounted or you're going use a rescue
media or rescue image of some kind.
>> >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 ?
No. I suppose I should.
>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.
I do not understand what this has to do with pty's or what
a "USB pty" is. Do you mean tty handling? I believe gpm can already
put characters into the console's input stream, so I don't see any new
code being needed there.
>> 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 ?
It is not just a matter of passing along a copy of the descriptors.
The drivers are going to want to do something intelligent. To imagine
a pathalogical example, in HID, it is possible for a device to claim
that it is an exercise bicycle, keyboard and uninterruptible power
supply, and that it sends one event packet that includes combines the
status of all of these. The HID report descriptor is a potentially
very elaborate tree. You can build a dispatch mechanism for HID
drivers that might express an interest, in, say, complex boolean
expressions of different device types ("usages")--and I actually have
done this for an embedded system recently--but there will always be
devices where the user will want to customize process the inputs in
complex ways. For example, you might had an HID joystick interface,
and you might plug in a bank of four joysticks, but the HID report
descriptor might have some additional usages attached to the
description of those joysticks that indicates that three are mounted
together ("physical collection" in HID) and are labelled X, Y and Z.
That might effect the way you want to use those controls.
You could invent some sort of facility where the match making
is done at user level, but there does not seem to be a _quantitative_
basis needing to keep the path entirely in the kernel, so you might
as well have user land handle it, where you can be more flexible.
[I have deleted some the section at the end of this
discussion which covered the same topic as above.]
>> 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 ?
The connection is that in order to have such a facility your
system needs to be able to use user level keyboard input sources, so
it will already be using something like gpm.
>> 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.
It will only be supported on SMP-enabled kernels and it may
be some time before it's reliable, but think I really hope you're right.
>> 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.
By that logic, we should put entire Linux CD's in the kernel
tree.
>> 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 ?
HID should have been named CD for "compound device." An HID
report descriptor is a potentially very complex tree structure
(although, fortunately, it is easy to parse) and there can be all
sorts of weird types of devices that you want to handle in special
ways, where you are going to want to customize things.
As I said earlier, you could create a user land "match making"
interface and have the input loops in kernel, but, since I want to
run my mouse through gpm anyway, I don't really see an advantage to
putting more stuff in the kernel.
Personally, I would like to see most USB devices that have no
need to be in the kernel migrated to user land, but two reasons
distinguish the issue in the case of HID:
1. So far, it has been beyond me to develop a
MODULE_DEVICE_TABLE format (which is hard to change
once established) to accurately express all potential
HID interests.
2. There are some real applications that are harder because
I cannot manage these devices as flexibly as I would like
without making keyboard and mouse input go through
something like gpm anyhow. One example is the PDA
remote control I described. A more immediately applicable
example is that I would like to support multiple
monitor+keyboard+mouse workstations per computer to
help businesses reduce the costs and environmental
impact by reducing the number of computers they need.
>> 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 ?
If it turns out that people are happy with userland HID,
I would then prefer to have just boot mode keyboard support left
in (basically for debugging purposes). On the other hand, if somebody
still wants to maintain kernel HID, I suppose there is not harm
in it. I would just not have it enabled on in our standard
configuration.
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
