add devname module aliases to allow module on-demand auto-loading
in [Kernel]
|
Prev: [PATCH] rtc: Use genirq directly in rtc-wm831x
Next: [PATCH 1/2] perf TUI: Make 'space' be an alias to 'PgDn'
From: Kay Sievers on 20 May 2010 12:10 From: Kay Sievers <kay.sievers(a)vrfy.org> Subject: add devname module aliases to allow module on-demand auto-loading This adds: alias: devname:<name> to some common kernel modules, which will allow the on-demand loading of the kernel module when the device node is accessed. Ideally all these modules would be compiled-in, but distros seems too much in love with their modularization that we need to cover the common cases with this new facility. It will allow us to remove a bunch of pretty useless init scripts and modprobes from init scripts. The static device node aliases will be carried in the module itself. The program depmod will extract this information to a file in the module directory: $ cat /lib/modules/2.6.34-00650-g537b60d-dirty/modules.devname # Device nodes to trigger on-demand module loading. microcode cpu/microcode c10:184 fuse fuse c10:229 ppp_generic ppp c108:0 tun net/tun c10:200 dm_mod mapper/control c10:235 Udev will pick up the depmod created file on startup and create all the static device nodes which the kernel modules specify, so that these modules get automatically loaded when the device node is accessed: $ /sbin/udevd --debug ... static_dev_create_from_modules: mknod '/dev/cpu/microcode' c10:184 static_dev_create_from_modules: mknod '/dev/fuse' c10:229 static_dev_create_from_modules: mknod '/dev/ppp' c108:0 static_dev_create_from_modules: mknod '/dev/net/tun' c10:200 static_dev_create_from_modules: mknod '/dev/mapper/control' c10:235 udev_rules_apply_static_dev_perms: chmod '/dev/net/tun' 0666 udev_rules_apply_static_dev_perms: chmod '/dev/fuse' 0666 A few device nodes are switched to statically allocated numbers, to allow the static nodes to work. This might also useful for systems which still run a plain static /dev, which is completely unsafe to use with any dynamic minor numbers. Note: The devname aliases must be limited to the *common* and *single*instance* device nodes, like the misc devices, and never be used for conceptually limited systems like the loop devices, which should rather get fixed properly and get a control node for losetup to talk to, instead of creating a random number of device nodes in advance, regardless if they are ever used. This facility is to hide the mess distros are creating with too modualized kernels, and just to hide that these modules are not compiled-in, and not to paper-over broken concepts. Thanks! :) Cc: Greg Kroah-Hartman <gregkh(a)suse.de> Cc: David S. Miller <davem(a)davemloft.net> Cc: Miklos Szeredi <miklos(a)szeredi.hu> Cc: Chris Mason <chris.mason(a)oracle.com> Cc: Alasdair G Kergon <agk(a)redhat.com> Cc: Tigran Aivazian <tigran(a)aivazian.fsnet.co.uk> Cc: Ian Kent <raven(a)themaw.net> Signed-Off-By: Kay Sievers <kay.sievers(a)vrfy.org> --- arch/x86/kernel/microcode_core.c | 1 + drivers/md/dm-ioctl.c | 5 ++++- drivers/net/ppp_generic.c | 4 ++-- drivers/net/tun.c | 1 + fs/autofs4/dev-ioctl.c | 5 ++++- fs/btrfs/super.c | 5 ++++- fs/fuse/dev.c | 1 + include/linux/miscdevice.h | 3 +++ 8 files changed, 20 insertions(+), 5 deletions(-) --- a/arch/x86/kernel/microcode_core.c +++ b/arch/x86/kernel/microcode_core.c @@ -260,6 +260,7 @@ static void microcode_dev_exit(void) } MODULE_ALIAS_MISCDEV(MICROCODE_MINOR); +MODULE_ALIAS("devname:cpu/microcode"); #else #define microcode_dev_init() 0 #define microcode_dev_exit() do { } while (0) --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1599,12 +1599,15 @@ static const struct file_operations _ctl }; static struct miscdevice _dm_misc = { - .minor = MISC_DYNAMIC_MINOR, + .minor = MAPPER_CTRL_MINOR, .name = DM_NAME, .nodename = "mapper/control", .fops = &_ctl_fops }; +MODULE_ALIAS_MISCDEV(MAPPER_CTRL_MINOR); +MODULE_ALIAS("devname:mapper/control"); + /* * Create misc character device and link to DM_DIR/control. */ --- a/drivers/net/ppp_generic.c +++ b/drivers/net/ppp_generic.c @@ -2907,5 +2907,5 @@ EXPORT_SYMBOL(ppp_output_wakeup); EXPORT_SYMBOL(ppp_register_compressor); EXPORT_SYMBOL(ppp_unregister_compressor); MODULE_LICENSE("GPL"); -MODULE_ALIAS_CHARDEV_MAJOR(PPP_MAJOR); -MODULE_ALIAS("/dev/ppp"); +MODULE_ALIAS_CHARDEV(PPP_MAJOR, 0); +MODULE_ALIAS("devname:ppp"); --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1624,3 +1624,4 @@ MODULE_DESCRIPTION(DRV_DESCRIPTION); MODULE_AUTHOR(DRV_COPYRIGHT); MODULE_LICENSE("GPL"); MODULE_ALIAS_MISCDEV(TUN_MINOR); +MODULE_ALIAS("devname:net/tun"); --- a/fs/autofs4/dev-ioctl.c +++ b/fs/autofs4/dev-ioctl.c @@ -736,11 +736,14 @@ static const struct file_operations _dev }; static struct miscdevice _autofs_dev_ioctl_misc = { - .minor = MISC_DYNAMIC_MINOR, + .minor = AUTOFS_MINOR, .name = AUTOFS_DEVICE_NAME, .fops = &_dev_ioctl_fops }; +MODULE_ALIAS_MISCDEV(BTRFS_MINOR); +MODULE_ALIAS("devname:autofs"); + /* Register/deregister misc character device */ int autofs_dev_ioctl_init(void) { --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -832,11 +832,14 @@ static const struct file_operations btrf }; static struct miscdevice btrfs_misc = { - .minor = MISC_DYNAMIC_MINOR, + .minor = BTRFS_MINOR, .name = "btrfs-control", .fops = &btrfs_ctl_fops }; +MODULE_ALIAS_MISCDEV(BTRFS_MINOR); +MODULE_ALIAS("devname:btrfs-control"); + static int btrfs_interface_init(void) { return misc_register(&btrfs_misc); --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -18,6 +18,7 @@ #include <linux/slab.h> MODULE_ALIAS_MISCDEV(FUSE_MINOR); +MODULE_ALIAS("devname:fuse"); static struct kmem_cache *fuse_req_cachep; --- a/include/linux/miscdevice.h +++ b/include/linux/miscdevice.h @@ -31,6 +31,9 @@ #define FUSE_MINOR 229 #define KVM_MINOR 232 #define VHOST_NET_MINOR 233 +#define BTRFS_MINOR 234 +#define MAPPER_CTRL_MINOR 235 +#define AUTOFS_MINOR 236 #define MISC_DYNAMIC_MINOR 255 struct device; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 21 May 2010 08:00 On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk(a)redhat.com> wrote: > On Thu, May 20, 2010 at 06:07:20PM +0200, Kay Sievers wrote: >> This adds: >> alias: devname:<name> >> to some common kernel modules, which will allow the on-demand loading >> of the kernel module when the device node is accessed. > > I don't see any need for this for device-mapper: please leave dm out of this. > >> Ideally all these modules would be compiled-in, > > Why do you think that? Currently that's a matter for the user/distro to > decide! IMHO It's really not for the kernel to force a policy like this on its > users. If that's what you think, why does your patch instead not go the whole > way and refuse to allow these items even to be compiled as modules? Well, they will work fine as modules, and we need them rto work as such. It just does not make much sense if you are not a developer, and distros should not do what they do, but that's a different story, I don't want to get into. As a developer modules are more than useful, they make kernel development possible without constantly rebooting. This patch just brings the both needlessly different cases closer to each other, and does not require special init scripts anymore, to activate a specific sybsystem prior to using it. >> but distros seems too >> much in love with their modularization that we need to cover the common >> cases with this new facility. It will allow us to remove a bunch of pretty >> useless init scripts and modprobes from init scripts. > > Again, I don't see why this needs any kernel changes. If this was > important, any distro could deal with it itself trivially without needing > a kernel patch. That is actually to make systemd work on Fedora. And that's driven by the company you work for. You might just not work in the area where people fight against such problems, and don't know about them now. > Nack for the dm part of this from my point of view as it removes flexibility > with a 'one size fits all' approach that introduces a fixed minor number > into a dynamic world. There is no harm to make a well-know device node static, it just solves a lot of problems, and also makes it possible to work off of a static /dev. It's nothing different from the statically allocated numbers for /dev/dm-* Thanks for considering, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 21 May 2010 09:20 On Fri, May 21, 2010 at 13:51, Kay Sievers <kay.sievers(a)vrfy.org> wrote: > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk(a)redhat.com> wrote: > There is no harm to make a well-know device node static, it just > solves a lot of problems, and also makes it possible to work off of a > static /dev. To illustrate: On my box without this patch: dmsetup version Library version: 1.02.42 (2010-01-14) /proc/misc: No entry for device-mapper found Is device-mapper driver missing from kernel? Failure to communicate with kernel device-mapper driver. And the same box just with this patch, nothing else changed: dmsetup version Library version: 1.02.42 (2010-01-14) Driver version: 4.17.0 But its up to you to care if device-mapper just works, or if there is stuff like an init script with modprobe needed to load stuff that might never be needed. :) This is surely not about dynamic vs. static, it is about race-free on-demand activation of services and subsystems. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nikanth Karthikesan on 21 May 2010 09:40 On Friday 21 May 2010 18:41:38 Kay Sievers wrote: > On Fri, May 21, 2010 at 13:51, Kay Sievers <kay.sievers(a)vrfy.org> wrote: > > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk(a)redhat.com> wrote: > > > > There is no harm to make a well-know device node static, it just > > solves a lot of problems, and also makes it possible to work off of a > > static /dev. > > To illustrate: > > On my box without this patch: > dmsetup version > Library version: 1.02.42 (2010-01-14) > /proc/misc: No entry for device-mapper found > Is device-mapper driver missing from kernel? > Failure to communicate with kernel device-mapper driver. > > And the same box just with this patch, nothing else changed: > dmsetup version > Library version: 1.02.42 (2010-01-14) > Driver version: 4.17.0 > > But its up to you to care if device-mapper just works, or if there is > stuff like an init script with modprobe needed to load stuff that > might never be needed. :) > If this is needed, the dmsetup itself can do a `modprobe dm` instead of printing the message, "Is device-mapper driver missing from kernel?"? > This is surely not about dynamic vs. static, it is about race-free > on-demand activation of services and subsystems. > Loading dm-mod alone is enough for `dmsetup version`. But for other operations dm-mod may not be enough, as various other modules like dm-crypt, dm- mirror,... would also be required, depending on the dm table, which may or may not be installed. Thanks Nikanth > Thanks, > Kay > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 21 May 2010 10:00 On Fri, May 21, 2010 at 15:39, Nikanth Karthikesan <knikanth(a)suse.de> wrote: > On Friday 21 May 2010 18:41:38 Kay Sievers wrote: >> On Fri, May 21, 2010 at 13:51, Kay Sievers <kay.sievers(a)vrfy.org> wrote: >> > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk(a)redhat.com> wrote: >> > >> > There is no harm to make a well-know device node static, it just >> > solves a lot of problems, and also makes it possible to work off of a >> > static /dev. >> >> To illustrate: >> >> On my box without this patch: >> dmsetup version >> Library version: 1.02.42 (2010-01-14) >> /proc/misc: No entry for device-mapper found >> Is device-mapper driver missing from kernel? >> Failure to communicate with kernel device-mapper driver. >> >> And the same box just with this patch, nothing else changed: >> dmsetup version >> Library version: 1.02.42 (2010-01-14) >> Driver version: 4.17.0 >> >> But its up to you to care if device-mapper just works, or if there is >> stuff like an init script with modprobe needed to load stuff that >> might never be needed. :) >> > > If this is needed, the dmsetup itself can do a `modprobe dm` instead of > printing the message, "Is device-mapper driver missing from kernel?"? No, it can't. There is a delay until the node appears, unless you use devtmpfs. This can not be handled reliably by usual non-hotplug-aware tools. Also it could be any user of libdevmapper doing this. And running processes from libraries without the user of the lib knowing all the problems sub-processes create is not recommended at all. There is a good reason to let the kernel load the module on-demand, and not to code all sorts of racy stuff into tools. It's just open(), nothing else, and it is guaranteed by the kenrel to work, without any further synchronization. >> This is surely not about dynamic vs. static, it is about race-free >> on-demand activation of services and subsystems. >> > Loading dm-mod alone is enough for `dmsetup version`. But for other operations > dm-mod may not be enough, as various other modules like dm-crypt, dm- > mirror,... would also be required, depending on the dm table, which may or may > not be installed. Sure, but that is a detail, that can be solved by kernel-driven on-demand loading as well. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 Prev: [PATCH] rtc: Use genirq directly in rtc-wm831x Next: [PATCH 1/2] perf TUI: Make 'space' be an alias to 'PgDn' |