Module alias and table support

Hi guys,

Below is a preliminary patch which implements module aliases
and reimplements support for MODULE_DEVICE_TABLE on top of it. Tested on drivers/usb/net/pegasus.c, seems to work. The reason for doing this is so that userspace tools are shielded from ever needing to know the layout of the xxx_id structures.

The idea that modules can contain a ".modalias" section of
strings which are aliases for the module. Every module goes through a "finishing" stage (scripts/modfinish) which looks for __module_table* symbols and uses scripts/table2alias.c to add aliases such as "usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*" which hotplug can use to probe for matching modules.

scripts/table2alias.c +11 -0

+        /* which fields to match against? */
+        uint16_t        match_flags;
+
+        /* Used for product specific matches; range is inclusive */
+        uint16_t        idVendor;
+        uint16_t        idProduct;
+        uint16_t        bcdDevice_lo;
+        uint16_t        bcdDevice_hi;
+
+        /* Used for device class matches */
+        uint8_t         bDeviceClass;

scripts/table2alias.c +7 -0

+/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
+static int do_usb_table(void)
+{
+        struct usb_device_id id;
+        int r;
+        char alias[200];
+

scripts/table2alias.c +7 -0

+/* Looks like: pci:vNdNsvNsdNcN. */
+static int do_pci_table(void)
+{
+        struct pci_device_id id;
+        int r;
+        char alias[200];
+

Quoted 6 lines

The idea that modules can contain a ".modalias" section of
strings which are aliases for the module. Every module goes through a "finishing" stage (scripts/modfinish) which looks for __module_table* symbols and uses scripts/table2alias.c to add aliases such as "usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*" which hotplug can use to probe for matching modules.

How are you going to be able to handle hex values in that string? Or are you just going to rely on the fact that no valid hex value can be a identifier? You might want to add a ':' or something between fields to make it easier to parse, unless you've already written a bash and C parser that I can use :)

Hm, there goes my wonderful % decrease in size claims of diethotplug if we shink the original size of the module_table files...

We're already including other kernel header files, why not include usb.h too? That way we don't have to remember to update the structures in two places.

scripts/table2alias.c line 80

Quoted 2 lines

scripts/table2alias.c +2 -0

+        /* not matched against */
+        kernel_long     driver_info;

Or is it because of "kernel_long"? I'm pretty sure this field is only used within the kernel, and userspace does not care at all about it.

Quoted 13 lines

scripts/table2alias.c +13 -0

+/* Looks like "usb:vNpNdlNdhNdcNdscNdpNicNiscNipN" */
+static int do_usb_table(void)
+{
+        struct usb_device_id id;
+        int r;
+        char alias[200];
+
+        while ((r = xread(STDIN_FILENO, &id, sizeof(id))) == sizeof(id)) {
+                TO_NATIVE(id.match_flags);
+                TO_NATIVE(id.idVendor);
+                TO_NATIVE(id.idProduct);
+                TO_NATIVE(id.bcdDevice_lo);
+                TO_NATIVE(id.bcdDevice_hi);

scripts/table2alias.c line 140

Quoted 4 lines

scripts/table2alias.c +4 -0

+
+                strcpy(alias, "usb:");
+                ADD(alias, "v", id.match_flags&USB_DEVICE_ID_MATCH_VENDOR,
+                    id.idVendor);

Why are you doing this "preprocessing" of the flags and the different fields? If you do this, you mess with the logic of the current /sbin/hotplug tools a lot, as they expect to have to do this.

Also realize that if you do this, you can't generate the existing modules.*map files from the exported values.

In summary, I like the idea, and removing userspace knowledge of kernel structures is very nice. Just a few tweaks are needed.

Quoted 5 lines

scripts/table2alias.c line 80

Quoted 2 lines

scripts/table2alias.c +2 -0

+        /* not matched against */
+        kernel_long     driver_info;

Or is it because of "kernel_long"? I'm pretty sure this field is only used within the kernel, and userspace does not care at all about it.

It sucks to reproduce this, yes. But you need to know the size of the structure to grab it out of the object file. At least this way it's in the kernel source where we can change it.

Quoted 3 lines

Why are you doing this "preprocessing" of the flags and the different fields? If you do this, you mess with the logic of the current /sbin/hotplug tools a lot, as they expect to have to do this.

The plan was that /sbin/hotplug will gather all the fields for
whatever device has been inserted and create the modprobe string, eg:

		system("modprobe usb:v0506p4601dl01dh01dc01dsc01dp01ic01isc01ip01");

	Which will simply match the alias such as:
		usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*

Quoted 2 lines

Also realize that if you do this, you can't generate the existing modules.*map files from the exported values.

Hmm, I thought about enhancing this code to generate the .map
files as well (where it has all the information). BTW, did I break the current depmod map-generating code?

Quoted 6 lines

Quoted 5 lines

scripts/table2alias.c line 80

Quoted 2 lines

scripts/table2alias.c +2 -0

+        /* not matched against */
+        kernel_long     driver_info;

Or is it because of "kernel_long"? I'm pretty sure this field is only used within the kernel, and userspace does not care at all about it.

Quoted 3 lines

It sucks to reproduce this, yes. But you need to know the size of the structure to grab it out of the object file. At least this way it's in the kernel source where we can change it.

But can't we still just use the structure from the kernel header and not have to retype it here? If needed, we can change the type of driver_info into something more portable than what it is today. That would be much easier in the long run.

Quoted 2 lines

	Which will simply match the alias such as:
		usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*

Ah, you never told me about this plan :)

Yes, that would be very nice to have, pushing the logic out of the /sbin/hotplug code and into modprobe doesn't bother me. That just saved a _whole_ bunch of space in diethotplug, so you've made up for making the size smaller.

How would modprobe know which driver to load based on the above line? Are you going to scan all module files, or rely on something like the modules.*map files of today?

Just realize that if you pre-process the information like you are proposing to do, you can't get it back later, which changes the way things work.