We have a function in tty_io.c - wait_for_keypress(). All callers
can be converted to one function - change_floppy(fmt, ...); it tries to
eject floppy, prints a message and waits for user to press a key. So far
However, the thing needs to be callable from userland if we want
to evict that code out of kernel. Well, it's not a big deal - at that
point I have /dev/root (on ramfs) being an appropriate device node, so
ejecting is trivial (FDEJECT) and waiting for keypress also shouldn't
be hard. After all, it should be the same as turning ICANON off and doing
The problem being, wait_for_keypress() actually does something
almost, but not entirely unlike that. It calls a method of your console
- wait_key(). To start with, nothing else uses it. That in itself wouldn't
be a big deal. However, the method itself has different semantics for
different console drivers. On some of them (e.g. serial console) it actually
eats the character it had receieved. On some (e.g. normal VC) it just sits
and waits to be woken up by arrival of any keypress. Said arrival is
processed in a normal way - i.e. it's _not_ eaten.
Better yet, attach a VT220 to serial console and press any key that
would send multiple characters. Yup, that will eat one of them. Have fun
if you call wait_for_keypress() more than once. (On a normal keyboard
the effect will differ - next call will block).
IOW, this stuff looks like a big mess, just asking to be killed.
in wait_for_keypress() (userland variant):
* turn ICANON off
* flush the input
* restore settings
* kill wait_for_keypress(9)
* kill ->wait_key() and all its instances
* kill the keypress_wait - AFAICS we will end up removing everyone who
sleeps on it.
Are you OK with that variant? It's obviously a 2.5 stuff, but I'm
going to add that (eviction of late boot into userland and uncpio-to-ramfs)
into namespace patch and put it out for testing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/