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)
