Andrew Brown wrote:
> (1) ver seems to obsoleted in the "backwards compat" macro.
> conversely, its replacement, envdep, seems like it's not being used at
> all.  what's envdep supposed to do?

It was supposed as forward-compatible hook for future extension,
where the LKM would be able to specify some additional environmental
usage (i.e. API/ABI).
 
> (2) the order in which things are called seems backwards to me.  the
> fact that lkmdispatch() is called before load() means that load()
> can't do useful things like attach malloc types, for example, before
> the lkmdispatch() calls ends up falling into something that needs the
> malloc type (note that you have to build your kernel with KMEMSTATS in
> order to lose like this).  this means that all the *useful* things you
> *want* to do in an lkm specific scenario, you can't really do.
> perhaps we should reverse the order of lkmdispatch() and load() and
> unload() and lkmdispatch() in the LKM_E_LOAD and LKM_E_UNLOAD cases?

It matches the current use - existing LKMs want to run stuff
after the generic part succeeds and only if it succeeds.

BTW, it would be nice if the malloc types would be attached
automagically by generic code.

> (3) LKM_DISPATCH() isn't used anywhere in the tree that i can see.
> does someone have some languishing patches that make all the in-tree
> lkms use it?

The remapping via backward-compat DISPATCH() was good enuff for
in-tree LKMs and vmware, so it was not converted to LKM_DISPATCH().

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the Buddhist -=-
-=- masters say, ``You may notice during meditation that you        -=-
-=- sometimes levitate or glow.   Do not let this distract you.''   -=-