lkml.org 
[lkml]   [2003]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Module alias and device table support.
Date
In message <Pine.LNX.4.44.0301302351550.15587-100000@chaos.physics.uiowa.edu> y
ou write:
> On Fri, 31 Jan 2003, Rusty Russell wrote:
> > D: Introduces "MODULE_ALIAS" which modules can use to embed their own
> > D: aliases for modprobe to use. Also adds a "finishing" step to modules to
> > D: supplement their aliases based on MODULE_TABLE declarations, eg.
> > D: 'usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*' for drivers/usb/net/pegasus.o
>
> Some comments:
> o First of all, we're basically moving depmod functionality into the
> kernel tree, which I regard as a good thing, since we have to deal
> with actual kernel structures here. (The obvious disadvantage is that
> this makes it much easier to change these kernel structures, which
> breaks compatibility with other (user space) tools who expect a certain
> format)

Yes, but people already expect to run depmod at boot, and I haven't
made depmod safe for cross compiling. It could be done, but is it
worth it? I don't know.

BTW, the reason for using the alias mechanism is that aliases are
useful in themselves: consider you write a "new_foo" driver, you can
do "MODULE_ALIAS("foo")" and so no userspace changes are neccessary.
module-init-tools 0.9.8 already supported this.

> o My nm (RH 7.2 or .3, GNU nm 2.11.90.0.8) doesn't support --print-size.
> That'll probably affect many users.

OK. Fortunately I have a new version of the table2alias program which
takes the elf object directly, anyway, which has the benifit of being
faster, too.

> o What about collecting the struct xxx_device_id definitions into some
> header which could be included from the userspace code extracting
> the info instead of duplicating it. Still not quite fool-proof, but
> better than duplicating the info.

Great minds think alike: this was what Greg said. I did this in the
updated patch.

> o I think it'd be a good time to consider naming these sections e.g.
> "__discard.modalias", the license one "__discard.license" and have
> the kernel module loader discard "__discard*", so that it doesn't
> need to be aware of all that special crap, nor waste space for it.
> (Well, it needs to know about the license, anyway, so that's not such
> a good example).

I prefer to keep special symbols out of section names, so we can do
nice tricks later with __start_. So __discard_modalias would be my
preference if we're going to change it.

> o I'm not totally happy with the integration into the build system yet,
> but it'll clash with the module versioning changes anyway ;)

Yeah, I thought you'd say that 8). I consider this to be after
modversions in the queue, and I don't want to overload you.

> The modversions patch introduces a postprocessing stage for modules, which
> currently will only be invoked with CONFIG_MODVERSIONS set. However, I'm
> considering to make that pass mandatory either way. It basically obtains
> the list of all modules from the earlier stage, so it doesn't recurse and
> can thus be very fast. I'm currently coding the actual versioning process
> in C, since the shell / sed / grep based solution's performance isn't
> exactly great. In doing that, I already notice unresolved symbols and warn
> about them, which I think is an improvement to the build process, missing
> EXPORT_SYMBOL()s tend to go unnoticed quite often otherwise.

Well, you get them as warnings from depmod, but more timely checks is
good.

> Doing this postprocessing unconditionally would allow to generate the
> alias tables at this point as well.
>
> And while we're at it, we could add another section which specifies which
> other modules this module depends on (a.k.a which symbols it uses), making
> depmod kinda obsolete.

We can already figure what symbols it uses in depmod: the original
modprobe did just that, but Adam Richter complained about speed with
1200 modules (sure, it's < 1 second for most people, but Debian on an
old 486 would suck hard).

But putting the dependent module names in a section... I must say I
rather like that. I'll have to mull it over though.

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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