Messages in this thread | | | Subject | Re: keyboard problem with 2.6.6 | From | Sau Dan Lee <> | Date | 30 May 2004 14:40:31 +0200 |
| |
>>>>> "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.
Most package maintainers put dependencies in their 2.6 kernel image packages to force the user to also install module-init-tools. I can't see why that couldn't be done for userspace daemons.
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.
Vojtech> This is getting really annoying. Let me rephrase it Vojtech> again:
Vojtech> I don't have a keyboard on every of my systems. But when Vojtech> I have it and I have the driver running, I expect it to Vojtech> work.
So, you need to have a DRIVER running. How does putting the driver into kernel space make it different (for this argument)?
Vojtech> Regardless of what happened to the system. Regardless of Vojtech> userspace programs dying. Just work.
Userspace programs can die. Kernelspace code can Oops. Which is easier to recover? What happens when getty dies and how to recover? What happens when some kernel code oops? Do you lose data (held in RAM by other apps) in these cases?
Vojtech> Yes. The system doesn't need the keyboard drivers to Vojtech> function. The user does.
I don't, when I'm accessing via means other than a keyboard.
>> 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"?
Vojtech> Thanks for the fix.
I've been reporting this bug for 2.6.6 and 2.6.7-rc1, and it still hasn't been included in 2.6.7-rc2. What's happening? Should I report it again for 2.6.7-rc2?
>> And how about mouse drivers? They used to be in userland (gpm, >> XFree86 3.x -- 4.x, etc.) Why move it into the kernel?
Vojtech> You wanted to use a mouse click to dump registers?
GPM can be configured to do it, given that the SysRq feature can now be triggered from userland.
Vojtech> I'd have an interesting idea for you, though: If you want Vojtech> moving stuff to userspace, move the whole console Vojtech> there. The font handling, the keymap handling, colors, Vojtech> resolution, all that.
Vojtech> Just a simple program that uses the evdev interface to Vojtech> get the keyboard data for input, the fbdev interface for Vojtech> output, and the pty interface to communicate with the Vojtech> system.
I've never used fbdev. I don't plan to use it on any PC-type machines. It's so slow. I prefer the (S)VGA text modes and accelerated X11 drivers.
Vojtech> Now *that* would be a great project moving stuff to Vojtech> userspace.
But that restricts to fbdev.
Vojtech> It's in userspace. It's not running in the kernel Vojtech> space. It's subject to the scheduler and swapping. It Vojtech> doesn't react to interrupts immediately. I think that's Vojtech> quite clear.
Swappable is one of the features that I want. I often use my machines via X11 from one desktop computer. If the keyboard driver has been dormant for a long time, I'd prefer it to be swapped out, so as to free up some RAM for other programs.
If you don't want it to be swappable, you can add some mlock() calls. You don't have this *choice* for the kernel-space drivers.
Vojtech> Of course it's possible. There is not much that'd be Vojtech> impossible in operating systems. It's not convenient, Vojtech> that's all.
Now, it becomes a convenience issue, rather than a necessity issue.
Vojtech> It IS an option, not a requirement. But I WANT THE Vojtech> OPTION. If the keyboard handling is in userspace, I don't Vojtech> have the option of pressing a key combination and getting Vojtech> a register dump,
Why not?
Vojtech> because the daemon doing the processing may be dead Vojtech> already.
"may be". So, it's not always.
>> 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?
>> 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()?
Vojtech> The keyboard and mouse drivers don't handle Vojtech> keymaps. Those are handled in the console. The Vojtech> keyboard/mouse drivers are not necessarily _time_ Vojtech> critical, but they're critical. When your keyboard stops Vojtech> working, this often means your system is dead. (Think a Vojtech> laptop on an airplane.)
I've used my laptop in an airplane, and it works without problems. What would make the keyboard stop working in an airplane?
-- 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/
| |