Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] udev changes

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arjan Bouter <abouter AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] udev changes
  • Date: Sun, 29 May 2011 14:21:46 +0200

On Tue, 17 May 2011 15:42:38 -0500
David Kowis <dkowis AT shlrm.org> wrote:

> On 05/17/2011 02:24 PM, Ladislav Hagara wrote:
> > Instead of sleep 10 is possible to use:
> >
> > while ! -b /dev/sda6; do sleep 1; done
> > :-)
> >
> >
> > I found out and set these two variables in kernel (from 2.6.32):
> >
> > # zgrep CONFIG_DEVTMPFS /proc/config.gz
> > CONFIG_DEVTMPFS=y
> > CONFIG_DEVTMPFS_MOUNT=y
> >
> >>From http://cateee.net/lkddb/web-lkddb/DEVTMPFS.html :
> >
> > This creates a tmpfs filesystem, and mounts it at bootup and mounts it
> > at /dev. The kernel driver core creates device nodes for all registered
> > devices in that filesystem. All device nodes are owned by root and have
> > the default mode of 0600. Userspace can add and delete the nodes as
> > needed. This is intended to simplify bootup, and make it possible to
> > delay the initial coldplug at bootup done by udev in userspace. It
> > should also provide a simpler way for rescue systems to bring up a
> > kernel with dynamic major/minor numbers. Meaningful symlinks,
> > permissions and device ownership must still be handled by userspace.
> >
> >
> > Imho, it is good idea to have it enabled. After we must remove this from
> > %DEV/devices
>
> What about the people that don't think it's a good idea to have it
> enabled? Do we take care of that aspect as well? Do you propose we force
> everyone to have their kernel configured that way?
>
> If so, we need to mitigate the upgrade path. I'm all for new, good,
> useful features, but we need to provide an upgrade path that doesn't
> break existing installs.
>
> David
>

Now that the CONFIG_DEVTMPFS is mandatory for every single smgl box with udev
installed without any backward compatibility we'll need to fix a couple of
issues:

* "fix" the linux spell to drop support for kernels < 2.6.32 (possibly even
more kernels will *have* to be dropped because devtmpfs only lost it's
experimental status around January 2010)

* selinux support needs to be checked, as the kernel has *no* clue about
selinux context and all device files will be created with the default
context, possibly breaking existing installs.

* we need to document on the website that anyone using a initramfs *must*
mount
devtmpfs in that initramfs, because the kernel doesn't automount it in this
case.

* cauldron needs logic to make sure that CONFIG_DEVTMPFS is enabled both in
the
supplied kernel as in the kernel that's built during install when udev is
used because because otherwise the system will probably be unable to boot.

It's quite possible that a lot more needs to be fixed, these are just the few
issues that came to mind when I had the init.d spell fail because
CONFIG_DEVTMPFS is disabled in my kernel.

I'm all for useful new features, but is this really something we need to force
on every udev user?

Arjan Bouter


+=======
Source Mage GNU/Linux developer,
http://www.sourcemage.org
+===




Archive powered by MHonArc 2.6.24.

Top of Page