Subject: LKM_DISPATCH() and DISPATCH()
To: None <tech-kern@NetBSD.org>
From: Andrew Brown <atatat@atatdot.net>
List: tech-kern
Date: 02/18/2004 23:46:27
the current macros are:
#define LKM_DISPATCH(lkmtp, cmd, envdep, load, unload, stat) \
switch (cmd) { \
int error; \
case LKM_E_LOAD: \
lkmtp->private.lkm_any = (void *)&_module; \
if ((error = lkmdispatch(lkmtp, cmd)) != 0) \
return error; \
if ((error = load(lkmtp, cmd)) != 0) \
(void)lkmdispatch(lkmtp, LKM_E_UNLOAD); \
return error; \
break; \
case LKM_E_UNLOAD: \
if ((error = unload(lkmtp, cmd)) != 0) \
return error; \
return lkmdispatch(lkmtp, cmd); \
break; \
case LKM_E_STAT: \
if ((error = stat(lkmtp, cmd)) != 0) \
return error; \
return lkmdispatch(lkmtp, cmd); \
break; \
} \
return (0);
/* remap the old macro for backward source compatibility */
#define DISPATCH(lkmtp, cmd, ver, att, det, stat) \
LKM_DISPATCH(lkmtp, cmd, NULL, att, det, stat)
not that that's entirely needed, but i wanted to give a little context
for this.
(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?
(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?
stat()/lkmdispatch() i'm not sure about, though those breaks after
returns feel funny to me.
(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? someone was saying something about making more things
build as modules, so this stuff really ought to work properly. or at
least as well as possible.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
werdna@squooshy.com * "information is power -- share the wealth."