lkml.org 
[lkml]   [1998]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Module related stuff
Date
Hi Richard, 

> And come to think of it, I have no idea why there exists a
> get_module_symbol. I think perhaps it has been there for a
> long time and I didn't kill it with the rewrite early in the
> 2.1 series.

It is a useful way for a module to be able to tell what
exported funtions are available (at least for me).

> > Since get_module_symbol is currently not used anywhere in
> > the kernel, I doubt that this has affected anything else but what
> > I'm working on.
>
> You might consider not using it at all. What are you up to anyway?

I'm making all the 8390 based drivers (wd, ne, 3c503, ...) intelligent
enough to know that they have to load the 8390 core support. The
get_module_symbol tells me if 8390 support is there, regardless of
whether it is in-kernel, or loaded as a module. The support
for this is all tucked away in 8390.h, with only a one line change to
each driver that calls load_8390_module(). The parent module will never
fail to load with "unresolved symbol...." which is a step forward in
the luser-friendly department. The code probably explains itself better
than I can...

--------------- from 8390.h --------------------

#define NS8390_KSYSMS_PRESENT ( \
get_module_symbol(0, "ethdev_init") != 0 && \
get_module_symbol(0, "NS8390_init") != 0 && \
get_module_symbol(0, "ei_open") != 0 && \
get_module_symbol(0, "ei_close") != 0 && \
get_module_symbol(0, "ei_interrupt") != 0)

extern __inline__ int load_8390_module(const char *driver)
{

if (! NS8390_KSYSMS_PRESENT) {
int (*request_mod)(const char *module_name);

if (get_module_symbol("", "request_module") == 0) {
printk("%s: module auto-load (kmod) support not present.\n", driver);
printk("%s: unable to auto-load required 8390 module.", driver);
return -ENOSYS;
}

printk("%s: Attepmting to auto-load 8390 module.\n", driver);
request_mod = (void*)get_module_symbol("", "request_module");
if (request_mod("8390")) {
printk("%s: request to load the 8390 module failed.\n", driver);
return -ENOSYS;
}

/* Check if module really loaded and is valid */
if (! NS8390_KSYSMS_PRESENT) {
printk("%s: 8390.o not found or invalid or failed to load.\n", driver);
return -ENOSYS;
}

printk("%s: 8390 module loaded.\n", driver);
}

/* Map the functions into place */
S_ethdev_init = (void*)get_module_symbol(0, "ethdev_init");
S_NS8390_init = (void*)get_module_symbol(0, "NS8390_init");
S_ei_open = (void*)get_module_symbol(0, "ei_open");
S_ei_close = (void*)get_module_symbol(0, "ei_close");
S_ei_interrupt = (void*)get_module_symbol(0, "ei_interrupt");

return 0;
}
-----------------------------------

> Without knowing exactly what you are up to, I would recommend an
> interface like the following:

Ok, perhaps the above helps to clarify what I'm hacking at. I'll
have a look at using bits like what you outlined to flag the connection
between the two modules and see what I come up against. At the moment
8390.c doesn't require an init_module() function at all. I can see the
following case requiring some thought already:

wd.o loads, and subsequently autoloads 8390, marks it in use as
per your outlined method.

ne.o now loads, now 8390 is already present, but we must mark it as
in use by ne.o as well.

Anyways, thanks for the quick reply.
Paul.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.044 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site