[initramfs] wait_for_keypress() and ->wait_key()

[initramfs] wait_for_keypress() and ->wait_key()

[Alexander Viro]

	Folks, I'm playing with untar-to-ramfs stuff right now and it looks
like I've stumbled upon an interesting wart.

	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
so well.

	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
read().

	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.
Proposed solution:
in wait_for_keypress() (userland variant):
	* turn ICANON off
	* flush the input
	* read
	* restore settings
in kernel:
	* 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.

Re: [initramfs] wait_for_keypress() and ->wait_key()

[Russell King]

On Thu, Jul 12, 2001 at 08:00:27PM -0400, Alexander Viro wrote:
> ... On some of them (e.g. serial console) it actually
> eats the character it had receieved.
> ...
> 	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).

We could get round this easily by draining the serial port of charactesr
on entry to the wait_key method.  This would mean that the user would
have to press the key after the message has been displayed, which I don't
think is unreasonable, and probably reflects the keyboard behaviour more
accurately.

Note that as long as the device (whether it be VT or serial port) isn't
actually open, the characters pressed will be discarded in both the serial
port and keyboard case, so its not like you're storing up trouble later on.
Currently that is the case.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html