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
