On Mon, 20 Jul 2020 at 10:41, Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx> wrote: > > On (20/07/20 08:43), Marco Elver wrote: > > On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote: > > > > 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). 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 > > Can you give example of such CI systems? // that's a real question // None of ours should break; I agree the CI system is brittle if it relies on newlines. Parsed and displayed reports are changing, however -- what irks me is now all the reports sent to the LKML look ugly. Some random KASAN reports (just compare formatting): next (ugly): https://lore.kernel.org/lkml/000000000000c87b7305aadb6dba@xxxxxxxxxx/ mainline (normal): https://lore.kernel.org/lkml/000000000000f4ef6a05aa92ec6c@xxxxxxxxxx/ The same problem exists with lockdep reports, KCSAN reports, ... If newline-printks to insert blank lines are now banned, what are we to do? Send dozens of patches to switch everyone to printk(" \n")? Or some better suggestion? I cannot yet see how that is an improvement. (And if the behaviour is not reverted, please document the new behaviour.) That also doesn't yet address the ~400 other newline-printk users, and somebody needs to do the due diligence to understand if it's just a flush, or an intentional blank line. Thanks, -- Marco _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec