[SeaBIOS] [RFC] Document and rework debug levels
Kevin O'Connor
kevin at koconnor.net
Wed Apr 6 19:52:35 CEST 2016
On Wed, Apr 06, 2016 at 07:38:49PM +0200, Laszlo Ersek wrote:
> On 04/06/16 19:07, Kevin O'Connor wrote:
> > There are a number of debug levels in the SeaBIOS code today.
> > Unfortunately, much of the code does not follow any particular
> > standard for which debug level to use.
> >
> > This is becoming cumbersome for a few reasons:
> >
> > - some people want fewer debug messages to reduce boot time, but still
> > want critical messages (eg, error messages). Debug level 1 can be
> > too verbose while debug level 0 disables all messages.
> >
> > - some drivers become very verbose before other drivers, and thus
> > depending on a user's hardware, the user might get flooded with
> > messages they don't want before seeing the important messages from
> > the driver they were looking for
> >
> > - when writing a new driver, it's not easy for a developer to know
> > what debug level to choose
> >
> > I'm proposing that the debug levels be documented and that all of the
> > debug messages in SeaBIOS be reworked to follow that documentation.
> > Here are the debug levels I propose using:
> >
> > Level 1:
> > - SeaBIOS version banner
> > - Major error messages and major warning messages that are likely
> > indicative of an error
> > - Screen output (ie, printf) would also be available at this level
> > when screen-and-debug is true
> > Level 2:
> > - Critical memory layout information. This would include the e820
> > map prior to booting and similar information about UMB memory,
> > EBDA memory, BIOS table locations, etc.
> > Level 3:
> > - Found hardware for which there is a SeaBIOS driver and critical
> > information about that hardware (such as its address, hardware
> > version, hardware capabilities, etc.)
> > Level 4:
> > - Major code flow events between SeaBIOS phases (eg, post, boot,
> > resume phases)
> > Level 5:
> > - Code flow notifications at driver and subsystem startup (eg, "init
> > usb\n" type messages)
> > - Thread startup and shutdown messages
> > Level 6:
> > - Basic driver and subsystem debugging. This would be driver
> > specific messages that are not expected to be called with high
> > frequency (ie, not called on every disk access nor on every
> > keyboard access, etc.)
> >
> > Finally, for debug messages that could be called with high frequency
> > (eg, on each disk read), I propose defining a DEBUG_xyz at the top of
> > the particular driver source code file which would default to 9 and a
> > developer could change to a lower number when working on that code.
> > So, for example, DEBUG_xhci could be introduced and be used on
> > dprintf() messages that are invoked on each xhci transfer.
> >
> > As part of this proposal, the default debug level would change from
> > level 1 to level 4. Most dprintf level 1 calls in the code would
> > change to a level between 1 and 4. Most driver dprintf calls between
> > levels 3-8 would end up changing to level 6. Most dprintf calls with
> > 9 (or higher) would instead get a DEBUG_xyz definition.
> >
> > Thoughts?
>
> Seems well-thought-out to me. Any chance you could introduce symbolic
> constants too for the debug levels?
It would be nice to do that. However, I'm not sure if:
dprintf(DEBUG_memory, "my message\n");
would become too cumbersome due to the length of the symbol names.
Maybe adding wrappers (eg, debug_mem("my message") ) for the common
cases would avoid that problem.
Thanks,
-Kevin
More information about the SeaBIOS
mailing list