Prev: [tip:perf/core] perf: Fix wakeup storm for RO mmap()s
Next: [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver
From: Alasdair G Kergon on 21 May 2010 07:40
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?

> 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.

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.

Alasdair

--
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: Alasdair G Kergon on 21 May 2010 14:30
On Fri, May 21, 2010 at 03:55:21PM +0200, Kay Sievers wrote:
> 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.

Well until now we've tried to make everything possible treat device numbers as
dynamic, so I'd like to see some compelling logic behind the change.

> >> 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.

(Curiously this is not an issue I remember anyone raising with me as a problem
before.)

So what concepts are at stake here.
The module is available to the kernel but has not been loaded.
Some users do not need the module, so it should not be loaded by default.
Users who *do* need it would like it to get loaded automatically.

The matter under discussion is what mechanism to use to load it automatically.

The unique information is the module name so the mechanism should
ideally be tied directly to that. Anything wanting to use dm already
knows that name. The character device only becomes available later,
after the module is loaded, and userspace obtains it from /proc/misc.

The modprobe mechanism is tied to the name, so we should really look for
a solution based on that in the first instance.

A related matter - not yet mentioned or discussed between us - is how
the /dev/mapper/control node gets created and what it should be called,
as that name obviously goes against the udev standard of placing
everything in a flat /dev namespace with kernel-based names (so
something like '/dev/miscNNN' in this case) and creating symlinks from
the traditional filesystem locations like /dev/mapper/control.

Currently libdevmapper creates /dev/mapper/control as required based on
/proc/misc. Presumably we should now hand that over to udev as a
special case of the way we transferred the entries for the actual
devices with similar waiting & notification.

Currently tools (not libdevmapper) take responsibility for checking and
autoloading. E.g. lvm issues modprobes to autoload dm target modules.
(The kernel does also handle this but lvm doesn't use it because
it wants to know earlier that the operation would fail to avoid more
complex error-handling code.)

So I think we should first try to make an extension of the existing
mechanisms work. Everything is keyed off a single piece of information,
the module name, shared between userspace and kernel.

Alasdair

--
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/
 | 
Pages: 1
Prev: [tip:perf/core] perf: Fix wakeup storm for RO mmap()s
Next: [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver