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
prev parent 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