On (21/01/05 17:49), Petr Mladek wrote:
The following change solved the problem for me as well. It causes that ttynull is initialized after stdiocons console.
diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c index eced70ec54e1..602af4d30bd4 100644 --- a/drivers/tty/ttynull.c +++ b/drivers/tty/ttynull.c @@ -121,7 +121,6 @@ static void __exit ttynull_exit(void) tty_port_destroy(&ttynull_port); } -module_init(ttynull_init); -module_exit(ttynull_exit); +late_initcall_sync(ttynull_init); MODULE_LICENSE("GPL v2");
But I am not completely sure that it is the right solution.
Wow, hmm, puzzled. Why does it help?
It is strange. Console should get registered only when it was added by add_preferred_console(). It means that ttynull_init() should not register by default.
[..]
Some clue might be in stderr_console. It has to be explicitly unregistered to avoid staying as the default console, see unregister_stderr() in arch/um/drivers/stderr_console.c
Hmm... Some random thoughts:
Looking at arch/um/drivers/stderr_console.c - it doesn't have tty driver and it doesn't register one. So as far as console_device() concerned we still don't have a workable console - it will return NULL to tty_lookup_driver(), which will eventually return an error to filp_open("/dev/console"); hence we'd call register_ttynull_console() from console_on_rootfs(). So now we register ttynull as preferred console; hence when another console attempts to register itself we don't set CON_CONSDEV on it, because of `has_preferred_console`.
But I still don't understand why the initcall patch helped. Can you shed some light on it?
-ss