On Mon 2018-06-04 17:33:42, Steven Rostedt wrote: > On Thu, 31 May 2018 14:16:33 +0200 > Petr Mladek <[email protected]> wrote: > > > > enum log_flags { > > > - LOG_NOCONS = 1, /* already flushed, do not print to console */ > > > - LOG_NEWLINE = 2, /* text ended with a newline */ > > > - LOG_PREFIX = 4, /* text started with a prefix */ > > > - LOG_CONT = 8, /* text is a fragment of a continuation line */ > > > + LOG_NEWLINE = 1, /* text ended with a newline */ > > > + LOG_PREFIX = 2, /* text started with a prefix */ > > > + LOG_CONT = 4, /* text is a fragment of a continuation line */ > > > }; > > > > Please, do not renumber the bits if there is no real need for it. > > The format of the log buffer is read also by external tool like > > "crash". It seems that "crash" ignores these flags but... > > Then what's the problem for renumbering? I've renumbered internal flags > before. No one complained about it.
Steven, did you renumber enum log_flags or flags in a different subsystem? Note that struct printk_log is a bit special because it is used by the "crash" tool to implement the dmesg/log command. While "crash" tool does not have special handling for most other internal structures. I have double checked "crash" sources and it ignores these flags at the moment but it might change in the future => I suggest to do not renumber them if there is not a real need. Best Regards, Petr
