On 04/06/16 19:07, Kevin O'Connor wrote:
There are a number of debug levels in the SeaBIOS code
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:
- 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
- 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.
- Found hardware for which there is a SeaBIOS driver and critical
information about that hardware (such as its address, hardware
version, hardware capabilities, etc.)
- Major code flow events between SeaBIOS phases (eg, post, boot,
- Code flow notifications at driver and subsystem startup (eg, "init
usb\n" type messages)
- Thread startup and shutdown messages
- 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.
Seems well-thought-out to me. Any chance you could introduce symbolic
constants too for the debug levels?