Messages in this thread | | | From | Dmitry Torokhov <> | Subject | Re: keyboard problem with 2.6.6 | Date | Sun, 30 May 2004 12:26:05 -0500 |
| |
On Sunday 30 May 2004 07:40 am, Sau Dan Lee wrote: > >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes: > > >> Where it is now possible to move it out of kernel space WITHOUT > >> performance problems, why not move it out? > > Vojtech> Because it just works. > > Vojtech> 1) Upgrading the kernel will make your keyboard stop > Vojtech> working. Noone has installed your userspace daemons on > Vojtech> the system. > > Many people has already fallen into this trap with YOUR input system: > they didn't know they had to enable the 'i8042' and 'atkbd' features, > or they did but made them modules and didn't have any clue to insmod > them in the bootup scripts.
This was in development series (2.5) and was resolved by the time 2.6 came out so I really do not think it's a valid complaint.
> Vojtech> 2) The keyboard (and other input devices, so that you > Vojtech> don't complain about limiting this to the keyboard) > Vojtech> should work without requiring userspace to be running. > > Is a network interface an input device? Or do you just mean HID? > > USB devices (including USB keyboards and mice) require hot-plug (or > similar mechanisms) to load the corresponding modules before they can > work. Both /sbin/hotplug and /sbin/modprobe on my system are > userspace programs. > >
> Vojtech> And, it works just fine in the kernel, doesn't take up > Vojtech> any more space than as a program, so why to move it out? > > To leave more *swappable* RAM to userspace. >
On average it will take much more considering that you better have your keyboard daemon linked statically and residing.. umm.. initrd? initramfs? as you want your keyboard working very early.
> >> Yeah. At what rate are they arriving? 1200baud. Let's say > >> that' 9600bps. So, 1200 bytes per second. 1 byte in every 833 > >> microseconds. How come a processor at 33MHz (0.030 > >> microseconds per clock cycle) cannot cope with that? Assuming > >> that the processing of the data plus context switching plus > >> other overhead taks 1000 microseconds, that still shouldn't be > >> felt by a HUMAN user. Who has a reaction time of less than 100 > >> _milli_seconds? > > Vojtech> Can you say swap? > > Can you say mlock()? >
I though you wanted the thing to be swapped out? Btw, what are you going to mlock? Entirety of glibc?
-- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |