From: Andreas S. <an...@sc...> - 2002-09-30 21:52:35
|
I have an obvious, straight forward, well designed and not working implementation of a userspace agent to assign keyboards to VTs. It is not working because i missunderstood the return value of the call_userlandhelper() function to return the userland programms return value. That however is never returned, and I got convinced that this was so for a good reason: Whenever one waits for a userland programm to do something for the kernel, one is vulnerable for DOS attacks. So one tries to NEVER do that and it is not realistic to expect that anything along this line will ever make it into the kernel. (yes, module loading is different... :-) So if we want to have a userspace configuration/policy agent for input devices (Greg KH says it is the only way to slove the funky corner cases of USB devices) we need to take a two level approach: level one: the kernel assigns any vt to a keyboard at connection time and notifies userland. level two: Userland makes an informed decision and signals the kernel to reconfigure keyboard/vt accordingly. This could happen through a couple of interfaces: - append="" line in lilo.conf. this is not dynamic and tiresome to get all the info in that one line. - /proc filesystem: easy ascii interface, messy, but well documented, probatly the way of choice - ioctl(), binary interface, messy, well documented, second choice candidate and then there are syscalls and a nice filesystem that is only in 2.5.X, while i want this to work on 2.4 with ruby backported. I would like to get advice on the userland/kernel interface as well as the kernel internal reconfiguration of keyboards in regard to their attachment to VTs. Is it enough to kbd_disconnect() a given keyboard and connect it to an other vt following the procedure in kbd_connect, or are there any additional hoops to take? |