[nycbug-talk] Understanding sys/module.h , *module_t and *modeventhand_t
nikolai
nikolai at fetissov.org
Thu Apr 10 10:43:52 EDT 2008
>
>>>> Using cscope, I could find no definition for the "struct module"
>>>> structure.
>>>> *module_t points to "struct module" (which is, apparently, undefined).
>>>>
>>>> If I have to guess, I'd say the module structure then becomes defined
>>>> by
>>>> whatever
>>>> we make module_t point to, so long as it's a structure.
>>>>
>>>> Later in hello.c
>>>> modeventhand_t is set to point to our event handler function "load".
>>>> *modeventhand_t expects for it's first argument (module_t), a pointer
>>>> variable pointing to a structure type.
>>>> but load expects for it's first argument (struct module *module), a
>>>> dereferrenced pointer
>>>> to a module structure that exists, but isn't defined?
>>>>
>>>>
>>> You are wrong here - parameter declaration "struct module *module"
>>> means module here is a pointer (otherwise it would just be
>>> "struct module varname" - but people usually don't pass structures
>>> by value in C :)
>>>
>>>
>>>> What's really going on here?
>>>> And, here's a good question: What *is* the first argument being passed
>>>> to load in execution?
>>>>
>>>> I didn't see source for kldload, but I guess I'll hit the KLD man page
>>>> and maybe that will
>>>> explain things more.
>>>>
>>>> #######################################################################
>>>>
>>>> #/sys/sys/module.h
>>>>
>>>> ...snip...
>>>>
>>>> typedef struct module *module_t; /* Tim: Where is this module struct
>>>> defined? */
>>>> typedef int (*modeventhand_t)(module_t, int /* modeventtype_t */, void
>>>> *);
>>>>
>>>> /*
>>>> * Struct for registering modules statically via SYSINIT.
>>>> */
>>>> typedef struct moduledata {
>>>> const char *name; /* module name */
>>>> modeventhand_t evhand; /* event handler */
>>>> void *priv; /* extra data */
>>>> } moduledata_t;
>>>>
>>>> ...snip...
>>>>
>>>>
>>> I don't know what's actually being given to the function
>>> here, but suspect it's that "priv" thing above that is used
>>> as a pointer to "opaque" module-specific data structure
>>> that only your module would understand. I might be wrong.
>>>
>>>
> No the *priv pointer is useless here. NULL in the hello module. Unused
> extra data place holder.
>
> At some point, something is calling the event handler, in my module
> called "load" (evhand in the moduledata struct definition), or it's
> calling *modeventhand_t
> which is made to point to load in moduledata_t.
>
> If I'm understanding the process, SYSINIT is what's doing the work.
> At some point one of it's subroutines is calling on "load", and I'd like
> to know what is the first argument.
> If I'm guessing right, it is what defines the "struct module" structure,
> if "defines" is the right terminology here.
> As you point out, it's not defining it, but just redirecting the pointer.
>
Tim,
I think the easiest way to find out what's passed as that
first argument is to find an existing working module in the
source tree and try to figure out what it gets there and what
it does with it.
Some random pointers:
There got to be a table/list/hash of module pointers somewhere
there, most probably dynamically allocated.
Kernel linker needs to know about modules being loaded -
its duty is to parse elf, map the segments, and fixup
references.
Fun and Games with FreeBSD Kernel Modules (old):
http://packetstormsecurity.org/papers/unix/fbsdfun.htm
Dynamic Kernel Linker (KLD) Facility Programming Tutorial [Intro]
http://rlz.cl/books/Books/BSD/blueprints.html
I think the second one actually explains that module_t business.
Cheers,
--
Nikolai
> Digging around I found plenty of complicated stuff, but not anything
> that explains it..
> Thinking "lets look at kldload", best I came up with is:
> <sys/sysproto.h>
> ...snip...
> struct kldload_args {
> char file_l_[PADL_(const char *)]; const char * file; char
> file_r_[PADR_(const char *)];
> ...snip....
> int kldload(struct thread *, struct kldload_args *);
> ...snip....
>
> But, that kldload_args struct has some weird [] stuff going on. I looked
> up the PADL symbols, but that just raises more questions.
>
This is not complicated once you get the idea of separate
pre-processing (macros) and compilation :)
More information about the talk
mailing list