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: flux <flux AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] udev changes
  • Date: Sun, 29 May 2011 21:51:46 +0900

Arjan Bouter (abouter AT sourcemage.org) wrote [11.05.29 21:26]:
> 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

There are several problems here.

1) This should not be a requirement (at least not yet) in the first
place. This needs far more testing before it should be pushed onto
everyone. Specifically, it minimally needs a clear update path. A udev
that requires a new kernel feature should *not* go into stable until at
least this update path is in place to handle the change over. There
should also be far more testing to ensure that said upgrade path
actually works for different scenarios.

2) Cauldron does not need the logic you imply. The ISO kernel is built
from a maintained kernel config, so the config would only need to be
updated (pending the change actually goes into stable, but see point (1)
above). There is no requirement to test custom built kernels for
specific features, and it would not make sense to. If you build a custom
kernel, it's your own responsibility to make sure you build it with the
necessary options. For current udev in the stable grimoire you must have
tmpfs enabled, and there have never been any checks for the presence of
tmpfs in a kernel, either in cauldron or any of our other components.
One particular reason this is the case is because udev itself is
optional.

3) We've never marshalled what goes on in an initramfs employed by a
user, because we don't offer any. Any and all initram filesystems are
created by the user and thus the user's responsibility. Additionally,
there is still no requirement that the user mount devtmpfs in the
initramfs unless the user employs udev in the initramfs. Busybox
provides its own minimalistic device manager, mdev. One could also use a
static dev in the initramfs. This is all completely separate and
orthogonal to what is used in the booted system, as the initramfs and
the booted system are two distinct run-times.

4) Not all users install their kernel via the linux spell, so you can't
assume that putting a fix in the linux spell will guarantee the sanity
of the system. However, since the kernel options are ultimately the
user's responsibility, it's not a real problem since it's up to the user
to guarantee this particular sanity (again, we make no provisions
presently even for tmpfs support in the kernel, which is already
required for udev in the stable grimoire).

--
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpNJs4TrGrxF.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page