Re: Change of behaviour when console=null and ttynull driver is used

[Guillermo Rodriguez Garcia]

El jue, 16 mar 2023 a las 14:40, Guenter Roeck (<linux@xxxxxxxxxxxx>) escribió:
>
> On 3/16/23 03:29, 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).
> >
> > 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/
> >
>
> Let me know if/when you find a solution. In ChromeOS we have to carry
> reverts of commit 48021f981308 ("printk: handle blank console arguments
> passed in.") and commit 3cffa06aeef7 ("printk/console: Allow to disable
> console output by using console="" or console=null") to handle the
> same problem (the above mentioned commit didn't work and had odd side
> effects).

The kernel seems to specifically check for "" (empty string) or "null"
and in this case uses the ttynull driver. But apparently we can use
any other invalid string (e.g "invalid") to get the previous behaviour
(no console).

I am still checking if this has other side effects.

Best regards,

Guillermo Rodriguez Garcia
guille.rodriguez@xxxxxxxxx