RE: [PATCH v6 1/3] printk: Add line-buffered printk() API.

[David Laight]

From: Tetsuo Handa
> Sent: 07 November 2018 10:53
> 
> On 2018/11/06 23:35, Sergey Senozhatsky wrote:
> >> Since we want to remove "struct cont" eventually, we will try to remove
> >> both "implicit printk() users who are expecting KERN_CONT behavior" and
> >> "explicit pr_cont()/printk(KERN_CONT) users". Therefore, converting to
> >> this API is recommended.
> >
> > - The printk-fallback sounds like a hint that the existing 'cont' handling
> >   better stay in the kernel. I don't see how the existing 'cont' is
> >   significantly worse than
> > 		bpr_warn(NULL, ...)->printk() // no 'cont' support
> >   I don't see why would we want to do it, sorry. I don't see "it takes 16
> >   printk-buffers to make a thing go right" as a sure thing.
> 
> Existing 'cont' handling will stay for a while. After majority of
> pr_cont()/KERN_CONT users are converted, 'cont' support will be removed
> (e.g. KERN_CONT becomes "").

A though:

Why not make the printf lock slightly 'sticky'?
- If the output line is incomplete save the cpuid.
- If there is a saved cpuid that doesn't match the current cpu then spin for a bit.

Any callers of printk() have to assume they will spin on the buffer for the
longest printk formatting (and symbol lookup might take a while) so a short
additional delay won't matter.

Then two calls to printk() for the same line won't (usually) get split and
none of the callers need any changes.

	David

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