lkml.org 
[lkml]   [2004]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: keyboard problem with 2.6.6
From
Date
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:

>> >> What I hate is only the part where mouse/keyboard drivers
>> >> are now in kernel space. The translation of raw byte
>> >> streams into input events should be better done in userland.
>> >> One important argument is: userland program may be swapped
>> >> out. Kernel modules can't.
>>
Vojtech> Well, keyboard support was always in the kernel

Once in kernel space, forever in kernel space? What's the logic?

Where it is now possible to move it out of kernel space WITHOUT
performance problems, why not move it out?


Vojtech> - you need it there, because you need the keyboard
Vojtech> always to work

Then, why make 'i8042' and 'atkbd' modules? I still remember reading
web pages that early pioneers who migrated from 2.4 to 2.6.0-test*
encountered a problem: they didn't compile-in these modules, and hence
the system boot up without a responding keyboard. Despite that, the
system does work and daemons are running!

So, why is a the keyboard need to always work?


I've been testing 'i8042' module and my atkbd driver (and the
SERIO_USERDEV patch) through the network. I've been doing 'rmmod
i8042' many many times. The system DOES work without that module (and
keyboard functionality). Why are you saying that "you need the
keyboard always to work"? Again, is that the limit of your
imagination?

Are you aware of the i8042_shutdown bug, which I discovered and fixed?
How could I have found such a bug, if "keyboard has to always work"?


And how about mouse drivers? They used to be in userland (gpm,
XFree86 3.x -- 4.x, etc.) Why move it into the kernel?




>> I like the fact that 2.6.6 no longer assumes that the keyboard
>> must be there (and thanks for your work to modularize those
>> pieces of code). This assumption doesn't hold, for instance,
>> in some embedded systems, which has no keyboard controller and
>> can only be controlled via an RS232 port.

Vojtech> I meant that keyboard handling was never done in
Vojtech> userspace.

OK. Then, it's time to consider moving it to userspace.


Vojtech> Of course it is modular now, but that still counts as 'in
Vojtech> the kernel'.

How about my atkbd.c?



Vojtech> ;) On embedded systems, or when you have an USB
Vojtech> keyboard, you can leave the whole PS/2 stuff out.

Is it impossible to run daemons driving the keyboard (my atkbd.c,
should be invoked from inittab) and mouse (e.g. gpm) on embedded
systems? I mean, why MUST the keyboard and mouse drivers be in kernel
space?


Vojtech> But still, if you have a working keyboard, the handling
Vojtech> is done in the kernel, and you can do a register dump,
Vojtech> process listing, etc, even when the system is
Vojtech> crashed.

Why just the keyboard? For that purpose, we can use mouse buttons,
the power button, a joystick button, or even a home-brewed button
connected to the RS232 port or parallel port. Why *limit* that to the
keyboard?


Vojtech> You wouldn't be able to do that if the processing of the
Vojtech> byte stream was done in an userspace program.

Isn't it possible to monitor the kernel via a tty connected to the
serial line?


Vojtech> - even in the case of a crash, when all userspace
Vojtech> programs may already be dead.
>> There are still RS232 ports and the network.

Vojtech> Sure. How convenient it is to have to find an RS232
Vojtech> cable, when your keyboard is just next to you on the
Vojtech> table?

The keyboard should be made an *option*, not a *requirement* for that.
As an optional feature, yo shouldn't assume it for granted.



>> Can't SysRq be triggered from a program now, in addition to
>> using a keyboard?

Vojtech> It can. But if your userspace is dead, you cannot run
Vojtech> that program. And that's usually when you need sysrq.

So, why limit that to the keyboard only? Why can't my LED lid switch
do it?


>> Is that "improvement" significant for 1200 baud devices? Even
>> on a 386DX-33?

Vojtech> Yes. Very much significant. Exactly because they're
Vojtech> running at 1200 baud, you need get most of that little
Vojtech> data they're sending to you.

I don't understand this. The slower a device is, the lesser is the
need to handle the incoming data in kernel space. I can't understand
how 1200baud is fast enough to cause significant delays. Maybe, you
can enlighten me on that?


Vojtech> The problem is that you get jerky mouse movement. It
Vojtech> stays for a while on one place (when the buffer is
Vojtech> filled), and then jumps elsewhere (when it's
Vojtech> processed). You need to do the processing byte by byte,
Vojtech> as they arrive.

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> Yes, it does. Because it uses the _kernel_ input system
Vojtech> to do the interfacing work. But I don't see any benefit
Vojtech> of having to go to userspace and back again into the
Vojtech> kernel.

Flexibility. The keyboard driver can talk to another machine via a
TCP connection, for instance. The keyboard driver can be easily
modified and debugged -- all in user space -- without hanging the
kernel due to stupid bugs (e.g. NULL pointers). The keyboard driver
could be prototyped in Perl, C++, or any other high-level languages.
(It'd be possible to design a specific language to make it easier to
describe the state machine, than in a general purpose language like C,
making it possible to less programming-proficient users to change the
keyboard behaviours.)



Vojtech> Care to name any? Everything from raw SCSI handling to
Vojtech> presenting files to processes is done in the
Vojtech> kernel.

So, raw access is still available, just in case the kernel code
developers' imaginations are exceeded in some applications.


>> If you think those are kernel jobs, then you have an argument
>> for implementing Ghostscript completely in kernel, so that we
>> can cat mythesis.ps > /dev/psprinter, whether or not my printer
>> is a Postscript printer, and whether or not it is connected
>> locally or remotely, right?
Vojtech> Good argument. There are limits of what makes sense to do
Vojtech> in the kernel. Ghostscript is easier to do in userspace,
Vojtech> because it needs access to fonts, has a nontrivial
Vojtech> configuration, isn't time critical, etc. Good candidate
Vojtech> for userspace.

Keyboard and mouse drivers are also easier to do in userspace, because
that makes access to keymaps, mouse protocol modules, etc. easier.
Neither do I think keyboard/mouse drivers are time critical enough to
be absolutely placed in kernel space. Human beings do not work in
units of milliseconds.


--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

-
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    [from the cache]
©2003-2011 Jasper Spaans