[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBRiRu7hlwxSKHBg@alley>
Date: Fri, 17 Mar 2023 13:51:18 +0100
From: Petr Mladek <pmladek@...e.com>
To: Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
Cc: linux-kernel@...r.kernel.org,
Alejandro Vazquez <avazquez.dev@...il.com>,
Shreyas Joshi <shreyas.joshi@...mp.com>,
sergey.senozhatsky@...il.com, rostedt@...dmis.org,
shreyasjoshi15@...il.com, Guenter Roeck <linux@...ck-us.net>
Subject: Re: Change of behaviour when console=null and ttynull driver is used
On Thu 2023-03-16 11:29:26, Guillermo Rodriguez Garcia wrote:
> Hi all,
>
> We have several embedded systems where pass console= or console=null
> in production to disable the console.
>
> Later we check for this in user space: in our inittab we check if fd0
> is "associated with a terminal" (test -t 0); if so, we are in
> development mode and we open a debug shell; otherwise (console
> disabled) we just start the application.
>
> Recently [1] this behaviour has changed and now if we pass console= or
> console=null, the new ttynull driver is used. This breaks the check we
> were doing (test -t 0 always true now).
>
> [1]: https://lore.kernel.org/lkml/X%2FcDG%2FxCCzSWW2cd@alley/t/
This is actually exactly the problem that the change tried to solve.
Some systems failed to boot when there was no console and they tried
to write something at stdout.
> Is there a way to get the previous behaviour? If not, is there an easy
> way for userspace to detect whether the console device is a "real" tty
> or ttynull (other than trying to parse the kernel boot args, which
> would be a bit fragile).
A solution would be to check that /proc/consoles has ttynull as the
only registred console, for example:
grep -q ttynull /proc/consoles && test `cat /proc/consoles | wc -l` -eq 1
Would this work for you, please?
Best Regards,
Petr
Powered by blists - more mailing lists