KTR_SPAREx

[John Baldwin]

On Thursday, June 07, 2012 4:09:33 pm Alexander Leidinger wrote:
> On Tue, 5 Jun 2012 21:14:02 +0100 Attilio Rao <attilio at freebsd.org>
> wrote:
> 
> > 2012/6/5 Adrian Chadd <adrian at freebsd.org>:
> > > Hi,
> > >
> > > I'm very tempted to make if_ath use KTR_DEV, but then have an extra
> > > ath sysctl which does something like:
> > >
> > > if (sc->sc_ktr_enable)
> > >    KTR();
> > 
> > But the actual problem is that your output will be overwhelmed by the
> > clutter of all the other KTR_DEV consumers.
> > 
> > We very much need an much higher granularity on KTR classes and
> > possibly a way to use it on-the-fly for kernel development and I think
> > what I suggested earlier makes sense.
> 
> How much of the uncovered uses of KTR really need KTR (instead of
> dtrace)? How many of them are time critical enough that dtrace is not
> fast enough? How many of them need to run very early so that not enough
> kernel infrastructure is available to run dtrace (can we run dtrace
> scripts very early during boot (when enough kernel infrastructure is
> available, before anything in userland starts) like in Solaris)?

Can you run a dtrace script from ddb?  (Hint: you can run 'show ktr' from
DDB, and you can use ktrdump on a crash dump to get a timeline of events when 
doing post-mortem analysis.)

-- 
John Baldwin