From: Kay Sievers on 21 May 2010 16:30 On Fri, May 21, 2010 at 21:32, Alasdair G Kergon <agk(a)redhat.com> wrote: > On Fri, May 21, 2010 at 08:51:49PM +0200, Kay Sievers wrote: >> The kernel itself creates /dev/mapper/control today. > > Must have missed that patch:) > Userspace lvm and dm code is certainly not tied to that today. > > The device node that userspace lvm and dm tools use is under the > complete control of this userspace code: it chooses the name, and > creates or fixes it if it doesn't already exist with the required > properties: anything devtmpfs is relevant only if it guessed the > right name that this *completely independent* userspace code > chooses to use and already created it exactly as required. > > If we were to move to a fixed name for the control device and hand > control of that name to the kernel, then obviously this userspace > code would need adjusting to respect that. Upstream udev has no primary device node naming anymore, it's all controlled by the kernel. In fact, recent udev versions log errors if userspace defines names which disagree with the kernel-provided names, or the kernel-created nodes. There is no "abstraction" anymore, the kernel defines the API today, and device naming is 100% inside the kernel. Udev's job is manage permissions, and to create meaningful symlinks which may change during lifetime of a kernel device. The primary kernel device name is always in sync with "dmesg", "proc/sys" and "/dev" these days. Only the symlinks may change at any time, reflecting the current state of the device. 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 25 May 2010 06:00 On Tue, May 25, 2010 at 11:48, Alasdair G Kergon <agk(a)redhat.com> wrote: > On Tue, May 25, 2010 at 07:33:41AM +0200, Luca Berra wrote: >> what patch? > > Peter Rajnoha is working on a final version of this, which includes > tweaking the userspace logic to give supremacy to devtmpfs. Note, that this will also work without devtmpfs, it will be just udev pre-creating the nodes on startup, even when the modules aren't loaded. Any access to the "dead" device nodes will cause the kernel to load the corresponding module. We need this facility mainly for other subsystems, which depend on this behavior for some time already. 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/
|
Pages: 1 Prev: staging: hv: Fix race condition on IC channel initialization Next: ipc: increase IPCMNI_MAX |