On 30/08/18 15:07, Jan Beulich wrote: >>>> On 30.08.18 at 14:31, <andrew.coop...@citrix.com> wrote: >> Callers are inconsistent with whether they pass a newline to panic(), >> including adjacent calls in the same function using different styles. >> >> painc() not expecting a newline is inconsistent with most other printing >> functions, which is most likely why we've gained so many inconsistencies. >> >> Switch panic() to expect a newline, and update all callers which currently >> lack a newline to include one. >> >> This actually reduces the size of .rodata (0x07e3e8 down to 0x07e3a8) because >> a number of strings are passed to both panic() and printk(). As they >> previously differed by \n alone, they couldn't be merged. > I agree this is a nice side effect, but ... > >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> --- >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Wei Liu <wei.l...@citrix.com> >> CC: Stefano Stabellini <sstabell...@kernel.org> >> CC: Julien Grall <julien.gr...@arm.com> >> >> (Restricted to the core arch maintainers as this is a tree-wide piece of >> cleanup with no functional impact to other areas.) >> >> The observant amongst you might realise that this reverts parts of c/s >> 51ad90aea21c - What can I say? Several years of hindsight is very useful, >> and >> at the time I did ask the maintainers which option they thought would be >> better... > ... I think both the earlier and this change are heading in the > wrong direction: I would much rather see the newline omitted > everywhere, _including_ in panic() itself: This causes one line > less to scroll off the screen in case you don't have a serial > console.
I don't expect that suggestion would get anywhere if you put it to a vote with The REST. For one, it breaks any ability to construct a single line of text from multiple printk() calls (which we have plenty of examples of in the codebase), and it further deviates from everyone’s expectation of how printk() works (which is the very reason we've picked up all these inconsistencies since I last made them consistent). IMO, such a change would be detrimental, because either the code will get out of sync again (most likely), or there will extra review aggravation as people submitting code to normal expectations have their code rejected. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
