lkml.org 
[lkml]   [2004]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: keyboard problem with 2.6.6
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.223 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site