Re: [IDEA] Enable debugging in userspace?

[Marc Koschewski <marc@osknowledge.org>]

* Fabio Erculiani <lxnay@lxnaydesign.net> [2005-11-20 20:54:42 +0100]:

> Today, one idea is floating around me and bugging my brain (read: headache).
> If I could be a newbie, and if I have a problem with the latest and greatest 
> linux distro, I start googling and looking for a solution. The problem is 
> that someone write that I have to enable debugging mode in kernel 
> configuration, recompile everything and reboot. That's quite impossible for a 
> newbie, isn't it?
> So, why don't add an option to enable/disable debugging mode in sysfs?
> 
> Like:
> 
> /* DEBUG MODE ON */
> echo "1" > /sys/kernel/debugging/debug_mode
> /* DEBUG MODE OFF */
> echo "0" > /sys/kernel/debugging/debug_mode
> 
> I know that debugging code might (remove "might") increase the kernel size, 
> but men, we have >256MB of RAM and >1GB of hard drive space.
> 

Fabio,

basically I would rate such a 'solution' a pro. But first a few cons
came up my mind:

1.) If you globally enable 'debug_mode' the user (and even more the
    newbie) is blown away by the enormous messages that would show up
    and thus these would be rendered useless in some way.
2.) The debug messages would appear 'just in time'. No matter, if they
    do because of a fault or just for informational purposes. How do you
    want to achieve to stack the messages i the right order for someone
    who does NOT deal with a system's internal to interpret these
    messages correctly? I mean, we're not talking about such stuff as 

	    usbcore: registered new driver usbmouse

    We're talking about stuff like

	    hub->hdev[XXX]: hub->status->hub = XXX,

    OK, anything my be tagged with the module the info comes from but
    this would mean a) enormous amount of work to do tagging the
    messages and b) implementing the messages that'll be thrown, when
    the debug_mode is enabled.
3.) It would be a rather optional thing as probs have been located using
    back- and calltrace + friends. Important errors or failures are
    reported in the logs nevertheless.
4.) Worse problems (besides stuff as 'My ACX100 Wireless adaptor does
    not work out of the box' are usually fixed by the distros people who
    know how to handle kernel bugs.

Regards,
	Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/