Add a very limited DDB dumpon(8)-alike to MI dumper code

[cem]

Summary

This allows ddb(4) commands to construct a static dumperinfo during
panic/debug and invoke doadump(false) using the provided dumper
configuration (always inserted first in the list).

The intended usecase is a ddb(4)-time netdump(4) command.

[markj]

Looks like some code is missing?

[cem]

In D21448#466951, @markj wrote:

Looks like some code is missing?

Like a consumer? :-)

Work is in progress; I intend to post that as a separate revision.

[markj]

In D21448#466970, @cem wrote:

In D21448#466951, @markj wrote:

Looks like some code is missing?

Like a consumer? :-)

Work is in progress; I intend to post that as a separate revision.

Ah, ok.

Looks fine to me, but KPIs for use by DDB are typically named *_ddb (witness_ddb_*, stack_*_ddb, linker_ddb_*, etc.), so I'd suggest naming it dumper_ddb_{insert,remove}() instead. db_* is for interfaces implemented by DDB itself.

[markj]

In the absence of consumers it's hard to see whether dumper_remove() might ever try to free one of the static dumperinfos. Depending on how it pans out, it might make sense to give static dumperinfos a special flag to help catch that.

[cem]

Thanks — I'll plan to make the name change. Re: the flag, the idea is that this type of dumper is only added to the list during db/panic time, when no external event would cause a dumper_remove (unless I'm forgetting something). And then removed before normal context resumes (if !panic). So maybe the flag is redundant? It wouldn't hurt to add in any case.

[cem]

Rename the routines.

[markj]

I'm not sure the "_static" suffix really adds anything, FWIW.

[cem]

In D21448#467334, @markj wrote:

I'm not sure the "_static" suffix really adds anything, FWIW.

I've removed it/them in my git stack.