cvs commit: src/sys/net if_vlan.c

Yar Tikhiy yar at comp.chem.msu.su
Sat Aug 5 18:41:50 UTC 2006


On Fri, Aug 04, 2006 at 01:01:54PM -0700, Marcel Moolenaar wrote:
> On Fri, Aug 04, 2006 at 01:14:22PM -0400, John Baldwin wrote:
> > > 
> > > So, putting the kdb_backtrace() under KDB is not a matter of said
> > > function not being present without KDB, it's that we don't want
> > > to emit backtraces when debugging is not enabled. Backtraces are
> > > a debugging tool and it makes sense to emit them only when the
> > > kernel is configured for debugging.
> > 
> > In practice this ends up being redundant though as to have kdb_backtrace() 
> > actually do anything you have to have DDB in your kernel config, which 
> > requires KDB.
> 
> That's really an implementation detail. What if we get a new debugger
> backend that allows backtraces? What if the GDB backend is extended to
> allow backtraces?

Anyway, they all will require KDB to register with.

> The point is that kdb_backtrace() is there if you want a backtrace and
> you call it based on whatever option that makes sense at the call-site
> or even unconditionally if that's the right thing.
> Whether there's actually a backend that can make a backtrace is really
> a seperate issue. We just happen to implement backtracing and unwinding
> by debuggers, but with an unwinder in the kernel on ia64, we really
> don't need a debugger in order to make a backtrace and it's not that
> unrealistic that I create a backend that can only do backtraces...

Then it would be great to have that backend enabled by default.
Backtraces are good not only to those who do actual debugging.
Users could post them to the lists and so help developers.

> > Places that call kdb_enter() aren't all #ifdef KDB IIRC.  It's 
> > just a feature that kdb_foo() functions become NOPs when the kernel isn't 
> > configured for debugging, so I think the #ifdef KDB's would be redundant.
> 
> None of the kdb_*() functions in src/sys/kern/subr_kdb.c turn into
> NOPs when option KDB is not present. They are all unconditionally
> functional by design and should therefore be called conditionally
> by consequence.

At least kdb_backtrace() will just return if there is no active backend.

The KDB option seems to be used in two distinct cases.  One of them
is when a driver or subsystem can offer something to KDB.  E.g.,
sio(4) can do line break condition.  The other case is when a
consumer call to KDB is made, e.g., that to kdb_backtrace().  Now
KDB seems to be able to handle such calls even if they are made
unconditionally.  Of course, such calls will just return unless
there is an active backend.  Putting such calls under "#ifdef KDB"
seems redundant now.

As for the first case, such drivers could call something like
kdb_is_on() to decide if special actions are to be taken.  Using a
build-time option to control a link between two kernel parts not
depending on the option looks strange.  E.g., the KDB code is always
there, sio(4) is controlled by "device sio", but the ability of the
latter to handle line break condition depends on "options KDB".
Counter-intuitive, eh?

-- 
Yar


More information about the cvs-src mailing list