public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...
Date: Sun, 2 Mar 2014 13:10:03 -0500	[thread overview]
Message-ID: <CAGfcS_mfCvQuZSBCRXqWtxGG3CR6NLUcanTCg_Y9zSe96EEJDw@mail.gmail.com> (raw)
In-Reply-To: <CAK2H+edHWBYS6e_am0M3OCqKVS0CBC20vRAYLQUSyjFj9cOXAQ@mail.gmail.com>

On Sun, Mar 2, 2014 at 11:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
>    In the last few days there is a news announcement about needing to
> change kernel my configuration to enable CONFIG_FHANDLE to support
> udev-210. I'm currently at udev-208 and virtual/udev-208-r1 so no big
> deal yet. However reading the news announcement it appears this has
> more to do with systemd than anything else and I don't use systemd so
> does/will this effect my machines?

I'm going to avoid repeating Canek's points, which are basically
correct on the factual matters.

However, I will clarify a little about why you probably think the news
has something to do with systemd.

The big change in udev-210 is how persistent network device names are
implemented.  The file that implements the rules is changing names,
which has an impact on your if you're trying to override it (your
override will no longer work if you don't change the name to follow
suit).  Also, the new rule file now pulls in config settings from a
file that contains "systemd" in the filename.  If you want to tweak
the persistent naming without disabling it entirely, it would make
sense to try to do so by editing that file, regardless of whether
you're using systemd.  The file contains systemd in the name because
it is also used by systemd for network settings.  So, you have udev (a
binary) loading a rule file (text) which loads a config file (text).
This is analogous to openrc running an init script which sources a
config file - editing the config file is preferable to editing the
script but nothing prevents you from doing either.

> I think the Gentoo devs forked udev to make either mdev or eudev
> but when it was announced it was too new for me so I just let it go
> by. Maybe now it's time for me to look into making a change of some
> type? I see eudev in portage, but not mdev.

Ok, just some definitions:
udev - the upstream project that you're familiar with - it has
recently merged with systemd, which has resulted in some changes that
some find objectionable (changes in install paths, incorporation of
systemd in file/path names, etc)

eudev - a fork of udev that attempts to basically do the same thing as
udev, but preserving the paths/etc used in the project prior to the
systemd merge.

mdev - shorthand for busybox mdev.  This isn't a separate package.  If
you have busybox installed you can use a function it supports which
will populate /dev based on detected devices, in a manner similar to
udev.  It is much less functional that udev, but if you have a simple
system where you don't need hot-swap support and all the bells and
whistles, it will give you a /dev similar to what you probably would
find on most linux boxes 10 years ago.

>    A (really, really, really) quick scan of the current install docs
> makes me think sysvinit/OpenRC/udev is still the default for new
> installs. Is this true? If so why is this kernel change being
> required?

Udev is changing upstream - presumably because the new kernel features
are helpful in some way.  I haven't read the details.

>    Also, I seem to have virtual/udev installed which says it's about
> enabling switching between udev & eudev. However there are no files
> associated with virtual/udev. (equery files virtual/udev returns
> nothing) It appears I cannot install eudev without removing udev so
> this seems a big step to take:

virtual/udev is a virtual package.  Virtual packages are called
virtual because they don't install files.  They exist for dependency
purposes - a package can depend on the virtual which lets you pick
whether you want to use udev or eudev or something else without lots
of things breaking.

Eudev is a fork of udev and cannot co-exist with it.  It would be like
installing mariadb and mysql on the same system, or openoffice and
libreoffice.  So, if you want to install it portage will helpfully
suggest uninstalling udev.

I won't tell you what you should be doing, but before you switch from
the defaults (openrc+udev+sysvinit) you should probably make sure you
understand what you're getting into.  The upstream udev is certainly
what 99% of Linux users will be using in general for the foreseeable
future, though I can't really see you getting into trouble with eudev
or mdev (with many limitations on the latter).  Migrating between them
isn't very hard at the moment, though if config files/etc start
diverging between eudev and udev that will make it harder to switch
(depending on how much you tweak on your system).

Rich


  parent reply	other threads:[~2014-03-02 18:10 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-02 16:57 [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things Mark Knecht
2014-03-02 17:45 ` Canek Peláez Valdés
2014-03-02 18:12   ` Mark Knecht
2014-03-02 18:38     ` Canek Peláez Valdés
2014-03-02 18:10 ` Rich Freeman [this message]
2014-03-02 18:32   ` Mark Knecht
2014-03-02 18:42     ` Canek Peláez Valdés
2014-03-02 18:58       ` Mark Knecht
2014-03-02 20:04         ` B Vance
2014-03-03 17:15   ` Tanstaafl
2014-03-03 17:40     ` Rich Freeman
2014-03-03 18:12       ` Frank Peters
2014-03-03 18:20         ` Canek Peláez Valdés
2014-03-03 18:36           ` Barry Schwartz
2014-03-03 18:40             ` Canek Peláez Valdés
2014-03-03 18:57               ` Barry Schwartz
2014-03-03 19:10                 ` Canek Peláez Valdés
2014-03-03 19:10           ` Frank Peters
2014-03-03 19:20             ` Canek Peláez Valdés
2014-03-03 19:20             ` Mark Knecht
2014-03-03 21:51               ` Frank Peters
2014-03-03 22:00                 ` Rich Freeman
2014-03-03 22:02                 ` Mark Knecht
2014-03-03 19:26             ` Barry Schwartz
2014-03-03 18:32         ` Barry Schwartz
2014-03-03 17:44     ` [gentoo-amd64] " Duncan
2014-03-03 17:58       ` Canek Peláez Valdés
2014-03-03 18:38         ` Mark Knecht
2014-03-03 18:57           ` Rich Freeman
2014-03-03 19:09             ` Mark Knecht
2014-03-03 19:18           ` Drake Donahue
     [not found]           ` <5314d594.85a12b0a.3030.ffffda67SMTPIN_ADDED_BROKEN@mx.google.com>
2014-03-03 22:50             ` Mark Knecht
2014-03-03 19:43         ` Duncan
2014-03-03 19:56           ` Rich Freeman
2014-03-13 10:10           ` Duncan
2014-03-13 13:45         ` [gentoo-amd64] Systemd Was: Please get me straight about sysvinit vs. systemd [...] Duncan
2014-03-13 17:24           ` Phil Turmel
2014-03-13 17:55           ` Rich Freeman
2014-03-13 19:20           ` [gentoo-amd64] " Duncan
2014-03-15  6:21             ` Jonathan Callen
2014-03-15 10:11               ` [gentoo-amd64] Systemd and journald Was: Systemd Duncan
2014-03-03 17:47     ` [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things Canek Peláez Valdés

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfcS_mfCvQuZSBCRXqWtxGG3CR6NLUcanTCg_Y9zSe96EEJDw@mail.gmail.com \
    --to=rich0@gentoo.org \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox