[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABDcavZWz=YOvZnW8pkQmuTVjTDxPPoa0zOiC7A_0HAEg_Vi3w@mail.gmail.com>
Date: Thu, 16 Mar 2023 11:29:26 +0100
From: Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
To: linux-kernel@...r.kernel.org
Cc: Petr Mladek <pmladek@...e.com>,
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: Change of behaviour when console=null and ttynull driver is used
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).
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).
Thank you,
(If possible, please CC me in any replies)
[1]: https://lore.kernel.org/lkml/X%2FcDG%2FxCCzSWW2cd@alley/t/
--
Guillermo Rodriguez Garcia
guille.rodriguez@...il.com
Powered by blists - more mailing lists