Ah, that's nice.
>and I'm a bit confused about the "right" way to do
>console input in the monitor. The patches I've seen that do similar
>things (the kdb patch and the previous version of the monitor) are
>fairly device-specific -- the old kernel monitor does IO directly
>through serial_inb and serial_outb, and the kdb patch reads scancodes
>from th keyboard. I'd ideally like to write something that works for
>any arbitrary registered console, so those approaches are out.
Ofcourse.
>Is console->wait_key what I want?
Yes, at least for the serial console, wait_key returns the character
it waited for. The PC keyboard driver alas doesn't do this yet,
drivers/char/keyboard.c:keyboard_wait_for_keypress() always returns
zero.
You could also use console->read() if it's non-zero i.e. implemented
by the console driver you're using.
>If I want to do things with
>interrupts disabled (since I'd like to prevent anything else from
>running on the system while in the monitor), am I going to have to
>roll my own polling IO functions for the console types I care about?
You shouldn't really - the idea of the functions from 'struct console'
is that they should _always_ work and not depend on interrupts, memory
mappings, what have you. Again, this is true for the console functions
defined in the serial driver, but not for keyboard_wait_for_keypress().
If you could fix keyboard.c, well, great :)
Mike.
-- Indifference will certainly be the downfall of mankind, but who cares?- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/