public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Koschewski <marc@osknowledge.org>
To: Fabio Erculiani <lxnay@lxnaydesign.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [IDEA] Enable debugging in userspace?
Date: Sun, 20 Nov 2005 21:16:12 +0100	[thread overview]
Message-ID: <20051120201611.GA7981@stiffy.osknowledge.org> (raw)
In-Reply-To: <200511202054.42479.lxnay@lxnaydesign.net>

* 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

      reply	other threads:[~2005-11-20 20:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-20 19:54 [IDEA] Enable debugging in userspace? Fabio Erculiani
2005-11-20 20:16 ` Marc Koschewski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051120201611.GA7981@stiffy.osknowledge.org \
    --to=marc@osknowledge.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lxnay@lxnaydesign.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox