put symbolic links between drivers and modules in the sysfs tree
Subsystems (6)
RFC 1/1 put symbolic links between drivers and modules in the sysfs tree
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
If you look at debian at the moment, it uses a huge mapping table on /proc/scsi/* to do this. If we implement the sysfs feature, we can simply go from /sys/block/<device> to the actual device to the driver and then to the module with no need of any fixed tables.
The code is a first cut and introduces two new module APIs:module_add_driver() and module_remove_driver(). We need this because the generic device model driver has no current knowledge of modules. We could enhance it to have a struct module * in struct device_driver, but once we have the sysfs links which this patch provides, there didn't seem to be a compelling reason to add it to struct device_driver.
Comments?
James
===== drivers/base/bus.c 1.62 vs edited =====
drivers/base/bus.c +1 -0
@@ -553,6 +553,7 @@pr_debug ("bus %s: remove driver %s\n" , drv->bus->name, drv->name);driver_detach (drv);up_write (&drv->bus->subsys.rwsem); +module_remove_driver (drv);kobject_unregister (&drv->kobj);put_bus (drv->bus); }
===== drivers/scsi/hosts.c 1.101 vs edited =====
drivers/scsi/hosts.c +5 -0
@@ -130,6 +130,11 @@ goto out_del_classdev;scsi_proc_host_add (shost); +if (shost->hostt->module && shost->shost_gendev.parent && + shost->shost_gendev.parent->driver) +module_add_driver (shost->hostt->module, + shost->shost_gendev.parent->driver); +return error; out_del_classdev:
===== include/linux/module.h 1.79 vs edited =====
include/linux/module.h +5 -0
@@ -578,6 +578,9 @@#define __MODULE_STRING (x) __stringify(x) +/* forward reference for the module_add/remove_driver API */ +struct device_driver ; +/* Use symbol_get and symbol_put instead. You'll thank me. */ #define HAVE_INTER_MODULE extern void inter_module_register (const char *,struct module *,const void *);
@@ -585,5 +588,7 @@extern const void *inter_module_get (const char *);extern const void *inter_module_get_request (const char *,const char *);extern void inter_module_put (const char *); +extern void module_add_driver (struct module *,struct device_driver *); +extern void module_remove_driver (struct device_driver *);#endif /* _LINUX_MODULE_H */
===== kernel/module.c 1.120 vs edited =====
kernel/module.c +25 -0
@@ -34,6 +34,7 @@#include <linux/vermagic.h> #include <linux/notifier.h> #include <linux/stop_machine.h> +#include <linux/device.h> #include <asm/uaccess.h> #include <asm/semaphore.h> #include <asm/cacheflush.h>
@@ -2139,6 +2140,30 @@printk (" %s" , mod->name);printk ("\n" ); } + +void module_add_driver (struct module *mod,struct device_driver *drv) +{ +if (!mod || !drv) +return ; +if (!mod->mkobj) +return ; + +/* Note: Perhaps we should store this link in the +* device_driver structure as well (i.e. have a struct module * +* element). */ + +/* Don't check return code; this call is idempotent */ +sysfs_create_link (&drv->kobj, &mod->mkobj->kobj,"module" ); +} +EXPORT_SYMBOL (module_add_driver); + +void module_remove_driver (struct device_driver *drv) +{ +if (!drv) +return ; +sysfs_remove_link (&drv->kobj,"module" ); +} +EXPORT_SYMBOL (module_remove_driver);#ifdef CONFIG_MODVERSIONS /* Generate the signature for struct module here, too, for modversions. */
Quoted 10 lines · James Bottomley
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
If you look at debian at the moment, it uses a huge mapping table on
/proc/scsi/*to do this. If we implement the sysfs feature, we can simply go from /sys/block/<device> to the actual device to the driver and then to the module with no need of any fixed tables.
Quoted 8 lines
The code is a first cut and introduces two new module APIs:
module_add_driver()andmodule_remove_driver(). We need this because the generic device model driver has no current knowledge of modules. We could enhance it to have a struct module * in structdevice_driver, but once we have the sysfs links which this patch provides, there didn't seem to be a compelling reason to add it to structdevice_driver.Comments?
I like it. But I do think that this should be moved into the driver core, so I added a "struct module *" to "struct device_driver". Here's the patch that I just applied to my trees, based on yours. It is only the core changes (and yes, I did fix up the location of the functions in the module.h file and fixed the bug when modules were not configured in.) I'll post my usb core change after this, to show you how USB can be hooked up to it. I'll let you figure out what the best way to handle the scsi code would be.
thanks again for the patch.
greg k-h
---------
Put symbolic links between drivers and modules in the sysfs tree
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
If you look at debian at the moment, it uses a huge mapping table on /proc/scsi/* to do this. If we implement the sysfs feature, we can simply go from /sys/block/<device> to the actual device to the driver and then to the module with no need of any fixed tables.
drivers/base/bus.c +2 -0
@@ -529,6 +529,7 @@down_write (&bus->subsys.rwsem);driver_attach (drv);up_write (&bus->subsys.rwsem); +module_add_driver (drv->owner, drv);driver_add_attrs (bus, drv); }
@@ -553,6 +554,7 @@pr_debug ("bus %s: remove driver %s\n" , drv->bus->name, drv->name);driver_detach (drv);up_write (&drv->bus->subsys.rwsem); +module_remove_driver (drv);kobject_unregister (&drv->kobj);put_bus (drv->bus); }
include/linux/device.h +2 -0
@@ -106,6 +106,8 @@struct kobject kobj;struct list_head devices; +struct module * owner; +int (*probe) (struct device * dev);int (*remove) (struct device * dev);void (*shutdown) (struct device * dev);
include/linux/module.h +14 -0
@@ -451,6 +451,11 @@int unregister_module_notifier (struct notifier_block * nb);extern void print_modules (void ); + +struct device_driver ; +void module_add_driver (struct module *,struct device_driver *); +void module_remove_driver (struct device_driver *); +#else /* !CONFIG_MODULES... */ #define EXPORT_SYMBOL (sym)#define EXPORT_SYMBOL_GPL (sym)
@@ -540,6 +545,15 @@static inline void print_modules (void ) { } + +static inline void module_add_driver (struct module *,struct device_driver *) +{ +} + +static inline void module_remove_driver (struct device_driver *) +{ +} +#endif /* CONFIG_MODULES */ #define symbol_request (x) try_then_request_module(symbol_get(x), "symbol:" #x)
kernel/module.c +21 -0
@@ -34,6 +34,7 @@#include <linux/vermagic.h> #include <linux/notifier.h> #include <linux/stop_machine.h> +#include <linux/device.h> #include <asm/uaccess.h> #include <asm/semaphore.h> #include <asm/cacheflush.h>
@@ -2187,6 +2188,26 @@printk (" %s" , mod->name);printk ("\n" ); } + +void module_add_driver (struct module *mod,struct device_driver *drv) +{ +if (!mod || !drv) +return ; +if (!mod->mkobj) +return ; + +/* Don't check return code; this call is idempotent */ +sysfs_create_link (&drv->kobj, &mod->mkobj->kobj,"module" ); +} +EXPORT_SYMBOL (module_add_driver); + +void module_remove_driver (struct device_driver *drv) +{ +if (!drv) +return ; +sysfs_remove_link (&drv->kobj,"module" ); +} +EXPORT_SYMBOL (module_remove_driver);#ifdef CONFIG_MODVERSIONS /* Generate the signature for struct module here, too, for modversions. */
Quoted 2 lines · Greg KH
I'll post my usb core change after this, to show you how USB can be hooked up to it.
And here's the 3 line patch that I added to the usb core to hook up both the usb and usb-serial drivers to support the modules symlinks.
I'll go mess with the pci core now, but as there is no "struct module *" in the pci driver structure, it will take a bit of auditing to get them all hooked up properly.
thanks,
greg k-h
------
USB: add support for symlink from usb and usb-serial driver to its module in sysfs
drivers/usb/core/usb.c +2 -0
@@ -76,6 +76,7 @@ }static struct device_driver usb_generic_driver = { + .owner =THIS_MODULE , .name ="usb" , .bus = &usb_bus_type, .probe = generic_probe,
@@ -159,6 +160,7 @@ new_driver->driver.bus = &usb_bus_type; new_driver->driver.probe = usb_probe_interface; new_driver->driver.remove = usb_unbind_interface; + new_driver->driver.owner = new_driver->owner;usb_lock_all_devices (); retval =driver_register (&new_driver->driver);
drivers/usb/serial/bus.c +1 -0
@@ -120,6 +120,7 @@ device->driver.bus = &usb_serial_bus_type; device->driver.probe = usb_serial_device_probe; device->driver.remove = usb_serial_device_remove; + device->driver.owner = device->owner; retval =driver_register (&device->driver);
Quoted 10 lines · Greg KH
Quoted 2 lines · Greg KH
I'll post my usb core change after this, to show you how USB can be hooked up to it.
And here's the 3 line patch that I added to the usb core to hook up both the usb and usb-serial drivers to support the modules symlinks.
I'll go mess with the pci core now, but as there is no "struct module *" in the pci driver structure, it will take a bit of auditing to get them all hooked up properly.
Here's that patch, if anyone cares...
thanks,
greg k-h
------
PCI: add "struct module *" to struct pci_driver to show symlink in sysfs for pci drivers.
drivers/pci/pci-driver.c +1 -0
@@ -417,6 +417,7 @@ drv->driver.bus = &pci_bus_type; drv->driver.probe = pci_device_probe; drv->driver.remove = pci_device_remove; + drv->driver.owner = drv->owner; drv->driver.kobj.ktype = &pci_driver_kobj_type;pci_init_dynids (&drv->dynids);
include/linux/pci.h +2 -0
@@ -632,9 +632,11 @@ unsigned int use_driver_data:1; /* pci_driver->driver_data is used */ }; +struct module ;struct pci_driver {struct list_head node;char *name; +struct module *owner;const struct pci_device_id *id_table;/* must be non-NULL for probe to be called */ int (*probe) (struct pci_dev *dev,const struct pci_device_id *id);/* New device inserted */ void (*remove) (struct pci_dev *dev);/* Device removed (NULL if not a hot-plug capable driver) */
Quoted 4 lines · James Bottomley
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
So what will your userland code do when you run it on a system with non-modular kernel currently running?
IOW, that's a fundamentally broken interface - you really want the same information regardless of modular vs. built-in.
Quoted 8 lines · [email protected] wrote:
Quoted 4 lines · James Bottomley
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
So what will your userland code do when you run it on a system with non-modular kernel currently running?
Totally agreed. If we didn't care about built-in drivers, then we might as well do cat /proc/modules.
BTW, I'm very glad that this is being worked on and that table in Debian's mkinitrd can finally die.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 2 lines · Herbert Xu
BTW, I'm very glad that this is being worked on and that table in Debian's mkinitrd can finally die.
btw does that mkinitrd already use
readlink /sys/block/sda/device/block/device
(which gives ../../devices/pci0000:00/0000:00:06.0/0000:03:0b.0/host1/1:0:0:0 as output)
the pci path that gives can easily be matched to modules.pcimap to find the information in case of a PCI device, so at least the table in your mkinitrd doesn't need to contain PCI devices.....
Quoted 10 lines · Arjan van de Ven
btw does that mkinitrd already use
readlink/sys/block/sda/device/block/device(which gives ../../devices/pci0000:00/0000:00:06.0/0000:03:0b.0/host1/1:0:0:0 as output)
the pci path that gives can easily be matched to modules.pcimap to find the information in case of a PCI device, so at least the table in your mkinitrd doesn't need to contain PCI devices.....
So tell me what happens when my root device is on MCA (which is one of my machines) or is a parisc internal device (which is another)...
Putting the modules link in relieves mkinitrd from having to understand anything about the bus types.
James
Quoted 8 lines · On Sat, 2004-09-25 at 03:38, [email protected] wrote:
Quoted 4 lines · James Bottomley
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
So what will your userland code do when you run it on a system with non-modular kernel currently running?
Not put a module in the initial ramdisk, since it would be unnecessary. The only information the patch seeks to add is the linkage between driver and module. So you can work back from sysfs to know which devices have which modules
Quoted 2 lines
IOW, that's a fundamentally broken interface - you really want the same information regardless of modular vs. built-in.
Not really. It you argue this about module *parameters*, I might agree, but not about what driver goes with what module...if the driver is build in, then the answer is a simple "none" and the link doesn't exist.
James
Quoted 8 lines · James Bottomley
Quoted 3 lines
So what will your userland code do when you run it on a system with non-modular kernel currently running?
Not put a module in the initial ramdisk, since it would be unnecessary. The only information the patch seeks to add is the linkage between driver and module. So you can work back from sysfs to know which devices have which modules
You're assuming that the kernel before/after the reboot have the same configuration. This is false in general.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 5 lines · Herbert Xu
Quoted 4 lines · James Bottomley
Quoted 3 lines
So what will your userland code do when you run it on a system with non-modular kernel currently running?
Quoted 7 lines
Quoted 4 lines
Not put a module in the initial ramdisk, since it would be unnecessary. The only information the patch seeks to add is the linkage between driver and module. So you can work back from sysfs to know which devices have which modules
You're assuming that the kernel before/after the reboot have the same configuration. This is false in general.
No I'm not. For an initrd/initramfs the only assumption would be that the boot device's driver is compiled in or modular. If this isn't true, the system won't boot anyway.
James
Quoted 11 lines · On Sat, Sep 25, 2004 at 08:38:19AM +0100…
Quoted 4 lines · James Bottomley
This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).
So what will your userland code do when you run it on a system with non-modular kernel currently running?
IOW, that's a fundamentally broken interface - you really want the same information regardless of modular vs. built-in.
I agree, and Rusty has some pending patches that provide that information for all drivers built into the system. When they are merged, this symlink will be created for those also (with a bit of tweaking, but it will happen.)
thanks,
greg k-h