RE: [PATCH v3] printk: allow direct console printing to be enabled always

[David Laight]

From: Petr Mladek
> Sent: 20 June 2022 17:58
> 
> On Mon 2022-06-20 01:33:02, Jason A. Donenfeld wrote:
> > In 5.19, there are some changes in printk message ordering /
> > interleaving which leads to confusion. The most obvious (and benign)
> > example appears on system boot, in which the "Run /init as init process"
> > message gets intermixed with the messages that init actually writes() to
> > stdout. For example, here's a snippet from build.wireguard.com:
> >
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -35,6 +35,18 @@ config PRINTK_CALLER
> >  	  no option to enable/disable at the kernel command line parameter or
> >  	  sysfs interface.
> >
> > +config PRINTK_DIRECT
> > +	bool "Attempt to flush printk output immediately"
> > +	depends on PRINTK
> > +	help
> > +	  Rather than using kthreads for printk output, always attempt to write
> > +	  to the console immediately. This has performance implications, but
> > +	  will result in a more faithful ordering and interleaving with other
> > +	  processes writing to the console.
> > +
> > +	  Say N here unless you really need this. This may also be controlled
> > +	  at boot time with printk.direct=0/1.
> > +
> 
> I am fine with the patch except for the config option. Is there
> any particular reason why we need it, please?
> 
> We should be careful to add new build options in general because they
> make building the kernel more complicated. People need to understand
> what each option is about and what they want.

Especially since most people use pre-built kernels.
I suspect that kernels only get build for very big and
very small/embedded systems.
For the latter you may want to completely remove using kthreads
for printk in order to shrink the kernel size.
But that doesn't look like what this option is for.

	David

> Kernel parameters are less intrusive. People need to care about
> it only when they need some special behavior. And everyone has
> its own default command line anyway. For example, I always use
> ignore_loglevel.
> 
> Best Regards,
> Petr

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)