Message-ID: <CABDcavb+W1x5ppQzzX3M09TNTr5vOnsNKuuMrpyNQ_vrTQyWKw@mail.gmail.com>
Date:   Wed, 22 Mar 2023 16:56:08 +0100
From:   Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Petr Mladek <pmladek@...e.com>, linux-kernel@...r.kernel.org,
        Alejandro Vazquez <avazquez.dev@...il.com>,
        sergey.senozhatsky@...il.com, rostedt@...dmis.org,
        shreyasjoshi15@...il.com
Subject: Re: Change of behaviour when console=null and ttynull driver is used

El mié, 22 mar 2023 a las 16:05, Guenter Roeck (<linux@...ck-us.net>) escribió:
>
> On Wed, Mar 22, 2023 at 09:33:32AM +0100, Guillermo Rodriguez Garcia wrote:
> > Hi Petr,
> >
> > El vie, 17 mar 2023 a las 13:51, Petr Mladek (<pmladek@...e.com>) escribió:
> > >
> > > 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.
> >
> > Well, I did not have any problem before this change.
> >
> > I understand that some systems had a problem (many others didn't, and
> > setting console= or console=null has been standard practice for a long
> > time). Since this change in behaviour could (and did) break things in
> > user space, perhaps it should have been made opt-in...
> >
> > >
> > > > 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?
> >
> > I was trying to avoid something like this as it feels like userspace
> > now needs to have too much knowledge of what the kernel is doing
> > internally, however I guess this is the best option.
> >
> > The suggested check seems to work but now I am seeing a different
> > (related?) issue: when I try to reboot from the console (using
> > busybox's reboot command), the system reboots normally if I am using a
> > "normal" console (e.g. console=ttyXXX), however when using
> > console=ttynull, the command takes 20-25 seconds to complete. I am not
> > sure why this would happen; if I understand correctly, for userspace
> > ttynull is just like a regular tty driver, so why would there be a
> > difference?
> >
>
> I think we may have seen something similar, causing us to revert the
> upstream patches in ChromeOS. We did not try to find out what exactly
> caused the problems.

If you have any further details on this that would be very helpful,
even if you didn't get to pinpoint the actual cause of the problem.

Thanks,

Guillermo Rodriguez Garcia
guille.rodriguez@...il.com

Powered by blists - more mailing lists