On Sun, Mar 2, 2014 at 11:57 AM, Mark Knecht <markkne...@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
