On Mon, Jul 20, 2020 at 9:45 AM Marco Elver <elver@xxxxxxxxxx> wrote: > On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote: > > On (20/07/18 14:10), Marco Elver wrote: > > > > > > It seems this causes a regression observed at least with newline-only > > > printks. I noticed this during -next testing because various debugging > > > tools (K*SAN, lockdep, etc.) use e.g. pr_{err,warn,info}("\n") to format > > > reports. > > > > > > Without wanting to wait for a report from one of these debugging tools, > > > a simple reproducer is below. Without this patch, the expected newline > > > is printed. > > > > Empty/blank lines carry no valuable payload, could you please explain > > why do you consider this to be a regression? > > Empty/blank lines are visually valuable. > > Did I miss a discussion somewhere that this change is acceptable? > Unfortunately, I can't find it mentioned in the commit message, and > therefore assumed it's a regression. > > As I said, a number of debugging tools use them to format reports to be > more readable (visually separate title and report body, and separate > parts of the report). While I can find it useful in some cases, though messages can be interleaved, ... > Also, such reports are often parsed by CI systems, > and by changing the reports, these CI systems may break. But those are > just the usecases I'm acutely aware of -- please see a full list of > newline-print users below. ...but this is a weak argument. If your CI relies on message rather on the ABI, you earn the breakage. Go and fix your CI to do sane things instead. > Breaking the observable behaviour of a widely used interface such as > printk doesn't seem right. Where the newline-print is inappropriate, > wouldn't removing that newline-print be more appropriate (instead of > forcing this behaviour on everyone)? -- With Best Regards, Andy Shevchenko _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec