Re: cvs commit: src/sys/sys ktr.h

From: Jeff Roberson <>
Date: Wed, 29 Dec 2004 19:36:49 -0500 (EST)
On Wed, 29 Dec 2004, Nate Lawson wrote:

> Jeff Roberson wrote:
> > On Wed, 29 Dec 2004, Nate Lawson wrote:
> >>Jeff Roberson wrote:
> >>
> >>>On Wed, 29 Dec 2004, Nate Lawson wrote:
> >>>
> >>>>Also, could someone please get us more KTR ids while they're at it?  We
> >>>>only have 2 left.
> >>>
> >>>
> >>>I think we should make one or to KTR_LOCAL's or something like that.  So
> >>>you can have a define in your file for KTR_MYCODE 0, and when you want to
> >>>debug it, define it to KTR_LOCAL.  There are a bunch of KTR ids that are
> >>>used for things that don't really need to be global that we could gc if we
> >>>do that.
> >>
> >>Isn't there a way to dynamically allocate ids, like sysctl does for oid?
> >
> > They need to be static at compile time or they always produce massive
> > bloat in the kernel.
> Right, I thought we did something like that for other subsystems.  I'm
> very fuzzy on the current best approach but in the past we used linker
> sets to gather a class of data at link time (including mod load).  If
> the linker set was an id placeholder for a particular type of debug
> data, the kernel could overwrite this with the actual runtime id.

We already have a runtime mechanism for disabling a particular class that
could tolerate dynamic class ids.  That's KTR_MASK.  The issue I'm talking
about, is the ability to compile it out.  Since gcc's dead code eliminator
doesn't run after link time, all ktrs would forever be compiled into the

> --
> Nate
Received on Thu Dec 30 2004 - 00:36:51 UTC