Dynamic ddb commands

[John Baldwin]

On Monday 02 February 2009 11:17:41 am Matthew Fleming wrote:
> > In general it is far easier to just add sysinit's than to hack directly on 
the 
> > kernel linker.  There are very few ddb commands, so one extra pointer or 
two 
> > per command is not a lot of space.
> 
> Respectfully, I disagree, for several reasons.
> 
> First, in order to make sysinit and sysctl work, the kernel linker
> needed to know that there are a set of elf sections that have special
> meaning.  Yes, using sysinits means that there are still only two elf
> sections of interest.

Yes, that is precisely the point, to keep the special knowledge in the kernel 
linker to a minimum.  This is why kernel modules use sysinit's as well, and 
thus device drivers, etc.  The kernel linker is already a bit complex, and 
I'd much prefer to keep non-linker related knowledge out of it as much as 
possible.

> Second, as I mentioned before, having ddb commands added mixed in with
> sysinits means that, if I have a bug in my sysinit I may not be able to
> use some of my ddb commands to debug it.  Even if DB_*COMMAND used
> SI_ORDER_FIRST, any sysinit with the same priority may come first.

You can still debug it, just not using your new commands.  But actually, as 
long as your sysinit's are after SI_SUB_KLD (as most of them are), then you 
can still use your debugging commands just fine.

> Next, if you want commands sorted globally, it could be done with either
> implementation.  But I think that commands that are defined by a module
> should be listed with others from that module.

Well, one of the "features" of ddb (IIRC) is that it allows "automatic" 
nicknames in that if you have a 'reallylongname' command you can just 
use 're' as an alias for it if 'reallylongname' is the only command that 
starts with 're'.  Handling that basically requires a sorted list.  Also, if 
you want to group commands in your module, that is easily accomplished by 
using an appropriate namespace.  E.g., prior to this when I used to use 'call 
foo()' as a poor-man's substitute, I added commands to debug de(4) and had 
them all start with 'tulip_*'.  You could use a similar practice to group 
your commands if desired.

> Last, changing struct command introduces a binary compatibility issue.
> Any older driver that had a ddb command (even if they never realized
> they couldn't access it) would need to be recompiled.  I am not sure of
> FreeBSD's binary compatibility policy, though, and it would presumably
> be across a major OS revision number.  So this is not a very compelling
> argument.

Correct, it is across major OS revisions, so it is ok to change it for 8.0.

-- 
John Baldwin