[gPXE-devel] [PATCH] [rom-o-matic] Add options to enable debug

Stefan Hajnoczi stefanha at gmail.com
Tue Jun 22 15:46:16 EDT 2010


On Tue, Jun 22, 2010 at 4:17 PM, Hogben, Colin H
<Colin.Hogben at ccfe.ac.uk> wrote:
> Stefan Hajnoczi wrote:
>
>> I think we should drop the limited set of pre-defined DEBUG= options
>> and allow the raw DEBUG= list to be specified.  This gives access to
>> every debuggable object file and the debug level can be set too (e.g.
>> scsi:3 enables DBG + DBG2).
>
> My thought was that a non-expert user would find a predefined list of
> options, with some explanation (maybe better than my brief texts),
> easier to use than having to enter a list of symbols.
>
> Perhaps it would be possible to combine both approaches, with an
> additional field along the lines you suggest, to cater for experts who
> are more intimately familiar with the source code but don't have a
> compilation environement.

My concern with a pre-defined list is that DEBUG= options specify
object files, not subsystems.  Things that appear as one feature or
subsystem are split over several object files internally.  A user
wanting to see DHCP-related debug messages might be disappointed with
the output of DEBUG=dhcp because they need DEBUG=dhcp,dhcpopts to get
a better picture.

The idea of having subsystem-specific debug checkboxes is very nice
for the user, but DEBUG= actually provides a lower-level mechanism
that doesn't match what the user expects from the GUI.  One solution
is to have subsystem checkboxes that enable a list of object files
(e.g. dhcp -> DEBUG=dhcp,dhcpopts) but I think that is extra work to
create and maintain as the codebase changes.

I'd like to share the use case that I think your work can solve and am
interested in hearing the use case you care about:

Users who run into issues with gPXE join the
#etherboot at chat.freenode.net IRC channel and ask for help.  Often more
information about the problem is needed so someone suggests building
with a DEBUG= option.  The user may not be able to build from source
so debugging the problem is blocked (the current workaround is for
someone to build a gPXE image for them).  ROM-o-matic DEBUG= support
would make it faster and easier to collaborate in support/debugging
sessions.

In this use case the user doesn't need to figure out the right DEBUG=
options, but they need to be able to help themselves to a debug image.
 Also, if the pre-defined DEBUG= list does not include the needed
object file, then it's back to square one.

Stefan


More information about the gPXE-devel mailing list