Date:	Fri, 21 May 2010 19:23:25 +0100
From:	Alasdair G Kergon <agk@...hat.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Nikanth Karthikesan <knikanth@...e.de>,
	Peter Rajnoha <prajnoha@...hat.com>,
	Milan Broz <mbroz@...hat.com>,
	Alasdair G Kergon <agk@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	"David S. Miller" <davem@...emloft.net>,
	Miklos Szeredi <miklos@...redi.hu>,
	Chris Mason <chris.mason@...cle.com>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Ian Kent <raven@...maw.net>, dm-devel@...hat.com
Subject: Re: add devname module aliases to allow module on-demand
	auto-loading

On Fri, May 21, 2010 at 03:55:21PM +0200, Kay Sievers wrote:
> On Fri, May 21, 2010 at 15:39, Nikanth Karthikesan <knikanth@...e.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@...y.org> wrote:
> >> > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk@...hat.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists