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?
|
