[nycbug-talk] Understanding sys/module.h , *module_t and *modeventhand_t
Tim A.
techneck at goldenpath.org
Thu Apr 10 00:47:51 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.
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.
> #include <stdio.h>
>
> typedef struct booohaaa* booohaaa_t;
> typedef int (*boo_f)( booohaaa_t, void* );
>
> int boo_ex( booohaaa_t p, void* ptr )
> {
> printf( "boo_ex( %p, %p )\n", p, ptr );
> }
>
> int main( int argc, char* argv[] )
> {
> boo_f func = boo_ex;
>
> (*func)( ( void* )0x0000ffff, ( void* )0xffff0000 );
>
> return 0;
> }
>
Great example summary. Other than your breakage example, in comparison,
I'm essentially trying to find the equivalent part in my scenario as your
( void* )0x0000ffff
in that booohaaa_t points to it.
But my scenario ends at the boo_ex declaration, and actually in better
comparision, boo_ex would be:
int boo_ex( struct booohaaa *booohaaa_t, void *ptr)
But, of course, you're passing the memory address?
That's kind of weird how you're doing that.
More information about the talk
mailing list