cvs commit: src/sys/sys ktr.h

[Jeff Roberson]

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
kernel.

>
> --
> Nate
>