On Wed, 27 Dec 2006, Garrett D'Amore wrote:
Cyril Plisko wrote:
Howdy,
While browsing sources under usr/src/uts I noticed that many
modules are reimplementing some sort of debug printf-like
functionality all over again. In many cases it looks like one
framework copying the defines from the other changing only
a prefix. Wouldn't it be beneficial for the kernel to have some
sort of generic DPRINTF/dprintf functionality, available to all
the components ? IMHO, besides overall cleanness it will
also allow developers to concentrate on their specific tasks
instead of re-inventing the wheel again and again.
May be there is something similar on the way already ?
It would be nice if we had some standard macros for this. The problem
is that developers want to turn on debugging in _their_ subsystem, and
nowhere else. Now the kernel could figure where the call came from, and
set up a table of kernel module -> debug tunable, which could be helpful.
Then you could use KPRINTF() calls, which evaluate to { } in a module
built without debug facilities.
<personal opinion>
Please no - it must be possible to runtime enable it. Even if the module
that uses it is compiled DEBUG. I think modules, even DEBUG modules, that
unconditionally spam the messages are very bad citizens.
I don't mind if for speed reasons, the [DK]PRINTF() evaluates to nothing
(read: is not compiled in) if DEBUG is not defined. But if it is, I still
don't want to be spammed by every off-the-shelf module just because I'm
using a debug kernel.
Can we put a "debuglevel" into "struct modlinkage" or so, to allow
selectively enabling these facilities per module ?
</personal opinion>
FrankH.
-- Garrett
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
