Messages in this thread | | | Date | Wed, 22 Mar 2023 08:05:27 -0700 | From | Guenter Roeck <> | Subject | Re: Change of behaviour when console=null and ttynull driver is used |
| |
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@suse.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.
Guenter
| |