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? Thanks, Laszlo _______________________________________________ SeaBIOS mailing list [email protected] https://www.coreboot.org/mailman/listinfo/seabios
