On Fri, May 21, 2010 at 03:55:21PM +0200, Kay Sievers wrote: > On Fri, May 21, 2010 at 15:39, Nikanth Karthikesan <knikanth@xxxxxxx> wrote: > > On Friday 21 May 2010 18:41:38 Kay Sievers wrote: > >> On Fri, May 21, 2010 at 13:51, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > >> > On Fri, May 21, 2010 at 13:34, Alasdair G Kergon <agk@xxxxxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
