Re: [PATCH] Module alias and table support

Re: [PATCH] Module alias and table support

[Adam J. Richter]

On November 26, 2002, David Brownell wrote:

>  >>> If we're going to use strings for device ID matching,
>  >>> then we can consolidate all of the xxx_device_id types into one:

>This is going to end up rewriting every MODULE_DEVICE_TABLE in the
>kernel, as well as hotplug and that depmod functionality, before
>hotplugging handles module loading again, isn't it? Somehow I'd
>rather not see us change so many things while we're "stabilizing".
[...]

	I already explained that this can be done by automated means,
(and it appears that Rusty Russell has already written much of the code
to do it):

| Initially, I would run a
| hacked version of depmod to output appropriate string-based device_id
| table declarations and append them to the corresponding .c files [...]


>If you're really talking "strings", with arbitrary whitespace,
>I rather like the idea of letting a bunch of key=value lines be
>used as an ID. [...]

	That sounds sensible.  That decision would be up to invidual
"bus types", but they'd probably mostly follow by example.  By the
way, here are a few other features that I think might be desirable in
choosing an ID format:

	- Unless a match pattern ends in "$", pattern matching should
	  return success if the ID has trailing garbage.  That way
	  it will be easy to add additional detail to device ID's
	  later (for example, Jeff Garzik talks about adding a PCI
	  revision field).

	- Maybe use your approach, or maybe avoid use of whitespace
	  and other characters with special meanings to the shell.
	  The question of what format is most "shell friendly" depends
	  on what shell script people have in mind to write for it.
	  For instance, without special characters, shell "case"
	  statements can correspond exactly to kernel pattern match text.
	  Examples of potential "real" uses would be appreciated.

	- Where this is easily achievable, use a format small enough
	  so that the ID string can be allocated in the kernel stack
	  to eliminate an error branch.

	- Prefer fixed-width hexadecimal, octal or binary numbers
	  to facilitate "bitmask" selections and because fixed-width
	  matching uses less stack space (and infintesmally less CPU).
	  "*" causes recursion in the match function, so use it
	  sparingly.

	- For hexademical, use capitalization opposite that of any text
	  buit into the ID string to reduce the chance of accidentally
	  writing a pattern that has an unanticipated incorrect match.

	- For devices that return an ASCII string (for example, ieee-1284
	  parallel port devices) maybe just use that.



>  >>> - No need for user level programs to query devices to generate
>  >>> hotplug information (goodbye pcimodules, usbmodules,
>  >>> isapnpmodules),
>  >
>  >>I think these can almost already go away now, with the info we have in
>  >>sysfs.

>The latest (cvs) hotplug scripts won't try to any of use
>those on 2.5 systems, it expects /sys/bus/$type/devices/*/*
>to expose all the necessary information (for coldplug, and
>for per-interface hotplug).

	USB /sys information appears to be only for the currently
selected configuration, but we want to match drivers for all possible
device configurations, even though most USB devices only define one.
Also, although the usb driverfs code is very clean, I'd still like to
be able to configure out sysfs for systems that don't need it, and yet
I might still want modules on those systems precisely because I want
to mimize kernel memory footprint (by only loading certain drivers for
users or situations that actually use them).


>  > static int try_every_driver_and_modprobe(struct device *dev, const char *id,
>  > 	    				  void *arg)
>  > {
>  > 	...
>  > 		request_module(id); /* or call hotplug or whatever */
>  > 	}
>  > 	BUG();	/* NOTREACHED */
>  > 	return -1;
>  > }

>Why a BUG?

	Because that line should never be reached.  However,
here is a cleaner (also untested) version of that routine:

static int try_every_driver_and_modprobe(struct device *dev, const char *id,
                                          void *arg)
{
        int try = 0;
        do {
                list_for_each(entry,&bus->drivers) {
                        struct device_driver * drv =
                                container_of(entry,struct device_driver,bus_list);
                        int result = try_this_driver(dev, id, drv);

                        if (result)
                                return result;
                }
	} while (try++ != 0 && request_module(id) == 0);
	return result;
}


>Hotplug is about more than just loading modules, and I'm not sure
>that "try every driver and hotplug" would make sense.

	The only activity being "tried" on each device is matching the
ID.  The probe function is only called if the ID matches.  The existing
code already works this way (with struct pci_device_id, usb_device_id,
etc.).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: [PATCH] Module alias and table support

[David Brownell]

>>This is going to end up rewriting every MODULE_DEVICE_TABLE in the
>>kernel, as well as hotplug and that depmod functionality, before
>>hotplugging handles module loading again, isn't it? Somehow I'd
>>rather not see us change so many things while we're "stabilizing".
> 
> [...]
> 
> 	I already explained that this can be done by automated means,
> (and it appears that Rusty Russell has already written much of the code
> to do it):
> 
> | Initially, I would run a
> | hacked version of depmod to output appropriate string-based device_id
> | table declarations and append them to the corresponding .c files [...]

Hmm, "would" doesn't sound like "it's working now" ... and the latest
available modutils for 2.5 (version 0.7) certainly does none of this.

One of the points being that the breakage comes from changing the
format supported by modutils.  Restoring current functionality should
IMO be high on the agenda .... USB has worked poorly in normal .configs
for a while now, because of this.

- Dave

Re: 2.5 modutils getting back device table support

[David Brownell]

Adam J. Richter wrote:
> On November 26, 2002, David Brownell wrote:
> 

>>If you're really talking "strings", with arbitrary whitespace,
>>I rather like the idea of letting a bunch of key=value lines be
>>used as an ID. [...]
> 
> 
> 	That sounds sensible.  That decision would be up to invidual
> "bus types", but they'd probably mostly follow by example.  By the
> way, here are a few other features that I think might be desirable in
> choosing an ID format:

Actually the transformation of MODULE_DEVICE_TABLE entries
into strings has never been done in the kernel, it's been
part of "depmod".

Remember that the strings are needed outside the kernel, when
the module is _not_ yet loaded so it'd be pointless to expect
any "bus type" sysfs logic to help.  Where would the IDs appear?


> 	- Unless a match pattern ends in "$", pattern matching should
> 	  return success if the ID has trailing garbage.  That way
> 	  it will be easy to add additional detail to device ID's
> 	  later (for example, Jeff Garzik talks about adding a PCI
> 	  revision field).

Erm, which pattern matching are you referring to ... what the kernel
does?  I don't think the kernel should want a regex engine.  And the
kernel's current device table matching logic doesn't fit neatly into
any reasonable regex.  (These fields are meaningful only if that one
has this bit set, those are only meaningful if value != -1, etc).

Likewise I think _positional_ syntax is something to get rid of.
It's error prone (position off-by-one --> bug cascade), and in
fact the order of the id components should be irrelevant even for
pattern matching.  So adding new components (pci rev, usb rev,
whatever), in any order should never break the IDs.


>> >>> - No need for user level programs to query devices to generate
>> >>> hotplug information (goodbye pcimodules, usbmodules,
>> >>> isapnpmodules),
>> >
>> >>I think these can almost already go away now, with the info we have in
>> >>sysfs.
> 
> 
>>The latest (cvs) hotplug scripts won't try to any of use
>>those on 2.5 systems, it expects /sys/bus/$type/devices/*/*
>>to expose all the necessary information (for coldplug, and
>>for per-interface hotplug).
> 
> 
> 	USB /sys information appears to be only for the currently
> selected configuration, but we want to match drivers for all possible
> device configurations, even though most USB devices only define one.

It's meaningless to try binding a driver to any non-current device
config.  There's a patch pending (from Oliver Neukom) to fix up some
relatively gaping integrity holes in config management.

I do agree there should probably be a better way to access information
about alternate configurations (and interface settings) than reading
the information in "usbfs" ... but a good solution likely means moving
away from that default policy of "one value per file".


> Also, although the usb driverfs code is very clean, I'd still like to
> be able to configure out sysfs for systems that don't need it, and yet
> I might still want modules on those systems precisely because I want
> to mimize kernel memory footprint (by only loading certain drivers for
> users or situations that actually use them).

This correspond to the original usb hotplug design requirement
of "must be able to run without usbfs".  Met by having hotplug
events describe the device, and having device table entries (NOT
used just for module loading!) encode many kinds of patterns.

And running without "sysfs" will probably mean the same thing
that running without "usbfs" previously meant:  there's no way
to ensure that "coldplug" scenarios work right, since there must
be times during system bootstrap where not enough of the OS is
running (files, daemons, ...) to handle early hotplug events, and
they can't be regenerated (or played back) later.

- Dave

Re: [PATCH] Module alias and table support

[David Brownell]

Adam J. Richter wrote:
> On Wed, Nov 27, 2002 at 01:53:58PM -0800, David Brownell wrote:
> 
>>One of the points being that the breakage comes from changing the
>>format supported by modutils.  Restoring current functionality should
>>IMO be high on the agenda .... USB has worked poorly in normal .configs
>>for a while now, because of this.
> 
> 
> 	I posted a patch a couple of days ago to revert 2.5.49/x86 to
> user level modules (no modversions or gplonly symbols in this version
> though).  However, I can't find the patch on marc.theaimsgroup.com, so
> here it is again.

Thanks, but I was hoping for a less radical solution:  just fixing
the "no device table support" bug fixed in the latest modutils ... I
do like the idea of forward motion in the module support, except that's
not what we've seen so far with modutils.

Seems like one of the issues is that there's really no maintainer
for modutils lately.  And I'm not even sure where to get the latest
modutils (more recent than 0.7) even if I were ready to patch them.

- Dave

Re: 2.5 modutils getting back device table support

[Adam J. Richter]

On November 27 2002, David Brownell wrote:
>Adam J. Richter wrote:
>> On November 26, 2002, David Brownell wrote:
>> 

>>>If you're really talking "strings", with arbitrary whitespace,
>>>I rather like the idea of letting a bunch of key=value lines be
>>>used as an ID. [...]
>> 
>> 
>> 	That sounds sensible.  That decision would be up to invidual
>> "bus types", but they'd probably mostly follow by example.  By the
>> way, here are a few other features that I think might be desirable in
>> choosing an ID format:

>Actually the transformation of MODULE_DEVICE_TABLE entries
>into strings has never been done in the kernel, it's been
>part of "depmod".

	That's the point of this change.


>Remember that the strings are needed outside the kernel, when
>the module is _not_ yet loaded so it'd be pointless to expect
>any "bus type" sysfs logic to help.  Where would the IDs appear?

	The ID would be the argument to modprobe (or
"hotplug pci want ...").  I showed where the strings would
be generated in the kernel in my previous posting at
http://marc.theaimsgroup.com/?l=linux-kernel&m=103828651528556&w=2

| /* In drivers/pci/pci-driver.c: */
| 
| void pci_for_each_id(struct device *dev, dev_id_callback_t callback,
|                       void *arg)
| {
|         struct pci_dev *pcidev = to_pci_dev(dev);
|         char id[100];
| 
|         sprintf(id, "pci-vendor=%04x-prod=%04x-...", pcidev->vendor,
|                 pcidev->product, ...);
|         return (*callback)(dev, id, arg);
| }


>> 	- Unless a match pattern ends in "$", pattern matching should
>> 	  return success if the ID has trailing garbage.  That way
>> 	  it will be easy to add additional detail to device ID's
>> 	  later (for example, Jeff Garzik talks about adding a PCI
>> 	  revision field).

>Erm, which pattern matching are you referring to ... what the kernel
>does?

	Yes.

>I don't think the kernel should want a regex engine.

	Not regex, just globbing ("*", "?", maybe "[0-9]").  It
will be shorter than the set of bus-specific match functions that
it replaces.  It might look something like this:

int match(char *pat, char *str)
{
	while (*pat != '*') {
		switch (*pat) {
			case '\0':
				return 1;	/* Trailing garbage OK */

			case '?':
				if (*str == '\0')
					return 0;
				goto char_matched;

			case '$':
				if (pat[1] == '\0')
					return *str == '\0';
				break;

			case '\\':
				pat++;  /* Yes, you can quote ascii 0. */
				break;

			default:
				break;
		}
		if (*pat != *str)
			return 0;
	char_matched:
		pat++;
		str++;
	}

	/* *pat == '*' */

	pat++;

	for (;;) {
		if (match(pat, str))
			return 1;
		if (*str == '\0')
			break;
		str++;
	}
	return 0;
}


>And the
>kernel's current device table matching logic doesn't fit neatly into
>any reasonable regex.  (These fields are meaningful only if that one
>has this bit set, those are only meaningful if value != -1, etc).

	Show me what you think is an example and I'll show you
how it would work with glob matching (no need for full blown
regular expressions).  You might want to take a look at Rusty's
converter, especially his "ADD" macro.  Here is the URL.

http://marc.theaimsgroup.com/?l=linux-kernel&m=103723352317709&w=2


>Likewise I think _positional_ syntax is something to get rid of.
>It's error prone (position off-by-one --> bug cascade), and in
>fact the order of the id components should be irrelevant even for
>pattern matching.  So adding new components (pci rev, usb rev,
>whatever), in any order should never break the IDs.

	That would be a benefit, but I don't think that the bugs that
it would catch and the extensbility would be worth the code complexity
in the kernel right now.  So far, the needs for expansion that people
have found have small and addressible by linear extension of a
pattern.  The bugs that your approach would catch are the sort of
thing that would be noticed readily: driver doesn't load.  If the id
strings are not huge, then drivers that have multiple device ids will
generarally have the strings lined up together, so alignment errors
will be rare (but, yes, I expect they'll happen, just as we have
alignment errors when people use unnamed initializers in pci device ID
tables).

	I'm also ambivalent about the longer ID strings that your
scheme implies.

	However, feel free to write a string pattern matches that is
small and detects mismatches quickly (an average of half of all PCI
device ID's will have to be checked every time someone inserts a
cardbus card).  I'll be happy to take a look when you do.

>> 	USB /sys information appears to be only for the currently
>> selected configuration, but we want to match drivers for all possible
>> device configurations, even though most USB devices only define one.

>It's meaningless to try binding a driver to any non-current device
>config.

	I don't understand why you say that.  If I plug in a device
and there is some way that the system can interface to it, it should
try to do so by default.

 
>There's a patch pending (from Oliver Neukom) to fix up some
>relatively gaping integrity holes in config management.

	I don't know what you're referring to or how it's relevant.


>I do agree there should probably be a better way to access information
>about alternate configurations (and interface settings) than reading
>the information in "usbfs" ... but a good solution likely means moving
>away from that default policy of "one value per file".

	By the way, I don't know what problem you're referring to in
usbfs, although I think that discussion is tangential and probably
completely irrelevant to this one.


>> Also, although the usb driverfs code is very clean, I'd still like to
>> be able to configure out sysfs for systems that don't need it, and yet
>> I might still want modules on those systems precisely because I want
>> to mimize kernel memory footprint (by only loading certain drivers for
>> users or situations that actually use them).

>This correspond to the original usb hotplug design requirement
>of "must be able to run without usbfs".

	I give little credence to ex cathedra proclamations.  I care
about underlying technical advantages and disadvantages.


>Met by having hotplug
>events describe the device, and having device table entries (NOT
>used just for module loading!) encode many kinds of patterns.

	The scheme that I've described happens to eliminate use of
usbdevfs by eliminating the need for the usbmodules program, and it
also does not need sysfs or usbdevfs for hotplug events (coldplug
is another matter as you point out below).


>And running without "sysfs" will probably mean the same thing
>that running without "usbfs" previously meant:  there's no way
>to ensure that "coldplug" scenarios work right, since there must
>be times during system bootstrap where not enough of the OS is
>running (files, daemons, ...) to handle early hotplug events, and
>they can't be regenerated (or played back) later.

	That's a good point for sysfs, but it would be pretty
easy to add a system call or ioctl to tell the kernel to walk
the device tree and regenerate the all the modprobe
(or "hotplug <bustype> want") events for all unbound devices.

	By the way, for non-tiny systems, we could also provide
a file interface for reading the strings generated by the generic
device ID string generators that I described (as in pci_for_each_id)
so that you could read the ID's from a file.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: [PATCH] Module alias and table support

[Rusty Russell]

In message <3DE53EF6.4080303@pacbell.net> you write:
> One of the points being that the breakage comes from changing the
> format supported by modutils.  Restoring current functionality should
> IMO be high on the agenda .... USB has worked poorly in normal .configs
> for a while now, because of this.

Absolutely.  I sent the patch to put the USB etc. tables back in
(merged in .48 IIRC).

Hopefully this is back together: the device-table-to-aliases stuff is
a separate step which can be argued on its own, and I think will
probably have to wait for 2.7 unless Greg is going to champion it.

The real win is simplicity and independence from the kernel
datastructures (which probably won't change during 2.6 anyway).

Hope that helps,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Module alias and table support

[David Brownell]

Rusty Russell wrote:
> In message <3DE53EF6.4080303@pacbell.net> you write:
> 
>>One of the points being that the breakage comes from changing the
>>format supported by modutils.  Restoring current functionality should
>>IMO be high on the agenda .... USB has worked poorly in normal .configs
>>for a while now, because of this.
> 
> 
> Absolutely.  I sent the patch to put the USB etc. tables back in
> (merged in .48 IIRC).

Hmm, with 2.5.50 and module-init-tools 0.8a two "modules.*map" files
are created -- but they're empty.  That's with the latest 2.5 modutils

   http://www.kernel.org/pub/linux/kernel/people/rusty/modules/

So that's not quite working yet.  I should clarify that this hasn't
been the only stumbling block for usb in recent kernels ... looks
as if some of the others (like "re-plugging" issues seemingly in
driver model code) may be gone, but this modutils-based regression
is particularly visible.

- Dave

Re: [PATCH] Module alias and table support

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]


> Hmm, with 2.5.50 and module-init-tools 0.8a two "modules.*map" files
> are created -- but they're empty.  That's with the latest 2.5 modutils
> 
>   http://www.kernel.org/pub/linux/kernel/people/rusty/modules/
> 
> So that's not quite working yet. ...

OK -- good news!

I now have USB hotplugging behaving again, with three patches on
top of 2.5.50 and modutils 0.8a :

- The <linux/module.h> patch included with your 0.8a announce:
    http://marc.theaimsgroup.com/?l=linux-kernel&m=103845080926386&w=2

- A tweak to that patch to still include <linux/elf.h> (to compile)

- The attached patch to your "modprobe", implementing "-n" and (so
   I can see it works at least partially) using "-v".

Will you merge the modprobe patch?  TIA!

- Dave







[-- Attachment #2: modprobe.patch --]
[-- Type: text/plain, Size: 2583 bytes --]

--- modprobe.c-orig	Thu Nov 28 13:18:37 2002
+++ modprobe.c	Thu Nov 28 13:34:55 2002
@@ -53,6 +53,9 @@
 
 #define MODULE_DIR "/lib/modules"
 
+int show_only = 0;
+int verbose = 0;
+
 static void fatal(const char *fmt, ...)
 __attribute__ ((noreturn, format (printf, 1, 2)));
 
@@ -384,7 +387,7 @@
 	for (dep = mod->dependencies; dep != NULL; dep = dep->next)
 		insmod(dep->module, options, NULL, 0, &call_history);
 
-	/* If we fail to load after this piont, we abort the whole program. */
+	/* If we fail to load after this point, we abort the whole program. */
 	mod->state = LOADED;
 
 	/* Now, it may already be loaded: check /proc/modules */
@@ -428,13 +431,18 @@
 	if (newname)
 		rename_module(mod, map, st.st_size, newname);
 
-	ret = syscall(__NR_init_module, map, st.st_size, options);
-	if (ret != 0) {
-		if (dont_fail)
-			fatal("Error inserting %s (%s): %s\n",
-			      modname, mod->filename, moderror(errno));
-		warn("Error inserting %s (%s): %s\n",
-		     modname, mod->filename, moderror(errno));
+	if (verbose)
+		printf ("insmod %s\n", mod->filename);
+
+	if (!show_only) {
+		ret = syscall(__NR_init_module, map, st.st_size, options);
+		if (ret != 0) {
+			if (dont_fail)
+				fatal("Error inserting %s (%s): %s\n",
+				      modname, mod->filename, moderror(errno));
+			warn("Error inserting %s (%s): %s\n",
+			     modname, mod->filename, moderror(errno));
+		}
 	}
 	free(map);
  out_fd:
@@ -505,6 +513,7 @@
 				   { "showconfig", 0, NULL, 'c' },
 				   { "autoclean", 0, NULL, 'k' },
 				   { "quiet", 0, NULL, 'q' },
+				   { "show", 0, NULL, 'n' },
 				   { "syslog", 0, NULL, 's' },
 				   { NULL, 0, NULL, 0 } };
 
@@ -515,7 +524,6 @@
 	struct utsname buf;
 	int opt;
 	int dump_only = 0;
-	int verbose = 0;
 	const char *config = NULL;
 	char *dirname, *optstring = NOFAIL(strdup(""));
 	char *modname, *newname = NULL;
@@ -523,7 +531,7 @@
 
 	try_old_version("modprobe", argv);
 
-	while ((opt = getopt_long(argc, argv, "vVC:o:kqsc", options, NULL)) != -1){
+	while ((opt = getopt_long(argc, argv, "vVC:o:knqsc", options, NULL)) != -1){
 		switch (opt) {
 		case 'v':
 			verbose = 1;
@@ -543,6 +551,9 @@
 		case 'k':
 			/* FIXME: This should actually do something */
 			break;
+		case 'n':
+			show_only = 1;
+			break;
 		case 'q':
 			/* FIXME: This should actually do something */
 			break;
@@ -550,7 +561,7 @@
 			/* FIXME: This should actually do something */
 			break;
 		default:
-			fprintf(stderr, "Unknown option `%s'\n", argv[optind]);
+			fprintf(stderr, "Unknown option `%c'\n", opt);
 			print_usage(argv[0]);
 		}
 	}

Re: [PATCH] Module alias and table support

[Rusty Russell]

In message <3DE54E53.8000005@pacbell.net> you write:
> Thanks, but I was hoping for a less radical solution:  just fixing
> the "no device table support" bug fixed in the latest modutils ... I
> do like the idea of forward motion in the module support, except that's
> not what we've seen so far with modutils.

Um, device table support went back in .49, at Adam's request (grand
plans are great and all that, but other maintainers are busy too, and
it'll take a while to get the new scheme sorted out).  You just have to
run depmod -a to generate the .xxxmap files.

The patch included in the 0.8 NEWS file allows the new depmod to
generate the tables too.

> Seems like one of the issues is that there's really no maintainer
> for modutils lately.  And I'm not even sure where to get the latest
> modutils (more recent than 0.7) even if I were ready to patch them.

Sorry, I thought I posted it a fair bit.
	http://www.[COUNTRY].kernel.org/pub/linux/kernel/people/rusty/modules

Hope that helps!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Module alias and table support

[Rusty Russell]

In message <3DE5BB48.5090606@pacbell.net> you write:
> Rusty Russell wrote:
> > In message <3DE53EF6.4080303@pacbell.net> you write:
> > 
> >>One of the points being that the breakage comes from changing the
> >>format supported by modutils.  Restoring current functionality should
> >>IMO be high on the agenda .... USB has worked poorly in normal .configs
> >>for a while now, because of this.
> > 
> > 
> > Absolutely.  I sent the patch to put the USB etc. tables back in
> > (merged in .48 IIRC).
> 
> Hmm, with 2.5.50 and module-init-tools 0.8a two "modules.*map" files
> are created -- but they're empty.  That's with the latest 2.5 modutils
> 
>    http://www.kernel.org/pub/linux/kernel/people/rusty/modules/
> 
> So that's not quite working yet.

Yes, there's a patch in the NEWS file, which is referred to at the top
of the README file.  Did you apply it?  If not, apply the one below
(which doesn't delete the #include <linux/elf.h>, which broke
CONFIG_KALLSYMS=y).

Hope this helps!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Name: Module Table Support for module-init-tools depmod
Author: Rusty Russell
Status: Tested on 2.5.50

D: This patch adds a "__mod_XXX_table" symbol which is an alias to the
D: module table, rather than a pointer.  This makes it relatively
D: trivial to extract the table.  Previously, it required a pointer
D: dereference, which means the relocations must be applied, which is
D: why the old depmod needs so much of modutils (ie. it basically
D: links the whole module in order to find the table).
D:
D: The old depmod can still be invoked using "-F System.map" to
D: generate the tables (there'll be lots of other warnings, and it
D: will generate a completely bogus modules.dep, but the tables should
D: be OK.)

diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.50/include/linux/module.h working-2.5.50-table/include/linux/module.h
--- linux-2.5.50/include/linux/module.h	Mon Nov 25 08:44:18 2002
+++ working-2.5.50-table/include/linux/module.h	Thu Nov 28 10:59:39 2002
@@ -14,6 +14,7 @@
 #include <linux/cache.h>
 #include <linux/kmod.h>
 #include <linux/elf.h>
+#include <linux/stringify.h>
 
 #include <asm/module.h>
 #include <asm/uaccess.h> /* For struct exception_table_entry */
@@ -40,11 +40,14 @@ struct kernel_symbol
 
 #ifdef MODULE
 
-#define MODULE_GENERIC_TABLE(gtype,name)	\
-static const unsigned long __module_##gtype##_size \
-  __attribute__ ((unused)) = sizeof(struct gtype##_id); \
-static const struct gtype##_id * __module_##gtype##_table \
-  __attribute__ ((unused)) = name
+/* For replacement modutils, use an alias not a pointer. */
+#define MODULE_GENERIC_TABLE(gtype,name)			\
+static const unsigned long __module_##gtype##_size		\
+  __attribute__ ((unused)) = sizeof(struct gtype##_id);		\
+static const struct gtype##_id * __module_##gtype##_table	\
+  __attribute__ ((unused)) = name;				\
+extern const struct gtype##_id __mod_##gtype##_table		\
+  __attribute__ ((unused, alias(__stringify(name))))
 
 /* This is magically filled in by the linker, but THIS_MODULE must be
    a constant so it works in initializers. */

Re: [PATCH] Module alias and table support

[Rusty Russell]

In message <3DE6924E.9060609@pacbell.net> you write:
> This is a multi-part message in MIME format.
> 
> --Boundary_(ID_oTV6oYegTuXHnGSwqC+1Lw)
> Content-type: text/plain; charset=us-ascii; format=flowed
> Content-transfer-encoding: 7BIT
> 
> 
> > Hmm, with 2.5.50 and module-init-tools 0.8a two "modules.*map" files
> > are created -- but they're empty.  That's with the latest 2.5 modutils
> > 
> >   http://www.kernel.org/pub/linux/kernel/people/rusty/modules/
> > 
> > So that's not quite working yet. ...
> 
> OK -- good news!
> 
> I now have USB hotplugging behaving again, with three patches on
> top of 2.5.50 and modutils 0.8a :
> 
> - The <linux/module.h> patch included with your 0.8a announce:
>     http://marc.theaimsgroup.com/?l=linux-kernel&m=103845080926386&w=2
> 
> - A tweak to that patch to still include <linux/elf.h> (to compile)

Good!  I think I'll release a 2.5.50 modules megapatch while I'm
waiting for Linus to merge.

> - The attached patch to your "modprobe", implementing "-n" and (so
>    I can see it works at least partially) using "-v".

And the compulsory spelling fix (Adam put that in, I'm sure it was to
check that people were paying attention).

Thanks, merged for 0.9 with the globals changed to locals and the
"wrong arg" fprintf removed (getopt prints a message) rather than
fixed.

Thanks very much for the testing and the patch!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Module alias and table support

[Greg KH]

On Thu, Nov 28, 2002 at 02:14:29PM +1100, Rusty Russell wrote:
> 
> Hopefully this is back together: the device-table-to-aliases stuff is
> a separate step which can be argued on its own, and I think will
> probably have to wait for 2.7 unless Greg is going to champion it.
> 
> The real win is simplicity and independence from the kernel
> datastructures (which probably won't change during 2.6 anyway).

Which, imho, is worth championing!  :)

I'm going to be in Austin next week, and I'll have some free time in the
evenings, so I'll try to take a look at your previous patch and see if I
can change it a bit to resolve the minor problems I had with it.

thanks,

greg k-h

Re: [PATCH] Module alias and table support

[Gerd Knorr]

>  Good!  I think I'll release a 2.5.50 modules megapatch while I'm
>  waiting for Linus to merge.

Good idea, that will simplify testing alot.  Right now I'm trying to
pick patches from the list, see some of them fail to apply, others fail
to build, that is somewhat annonying.  And I don't even start to
complain about architectures != i386 ...

  Gerd

-- 
You can't please everybody.  And usually if you _try_ to please
everybody, the end result is one big mess.
				-- Linus Torvalds, 2002-04-20