On 02/17/2016 07:37 AM, Michał Górny wrote: > >>>> * Both udev and eudev have pretty much feature parity, so there won't be >>>> any user-visible changes >>>> >>>> * udev upstream strongly discourages standalone udev (without systemd) >>>> since at least 2012 >>>> >>>> (see for example: >>>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html >>>> https://lkml.org/lkml/2012/10/3/618 >>>> ) >>>> >>>> So it'd be (1) following upstreams recommendations and (2) dogfooding >>>> our own tools. I don't see any downsides to this :) >>> I'm strongly against this, because: >>> >>> 1. It is a conflict-induced fork. As such, it will never be merged >>> upstream and it will never be supported upstream. In fact, it is >>> continually forces to follow upstream changes and adapt to them. eudev >>> is more likely to break because of the Gentoo developer(s) working hard >>> to merge upstream changes to their incompatible code. >> That was the entire point of the project. Upstream rejected any attempts >> to do things that we actually needed and broke things claiming the >> distributions were responsible for handling the breakage, so eudev was >> started on the basis that we needed a project that would ensure that >> changes in udev occur in a way that makes sense. > What things? Things like 'let's try to spawn this script third time in > case someone mounted something so that it happens to work this time'? > Yes, that old behavior really made sense. It did. Not having it made booting a lot more exciting, and exciting is bad.
Now you need to boot before you boot (mount all relevant filesystems before starting PID1?), which is fragile and suddenly makes the initramfs complex enough to require, err, a dhcp client, different fsck implementations, and pretty much all that would have been in /bin or /sbin before the /usr movearounding started. And firmware and kernel modules, like this it's easy to go >150MB for a compressed initramfs if you need firmware and a dhcp client to bring up the NFS share with /boot (hey, with ceph it's even more exciting ...) "initramfs is the new rootfs" - yeah, that sounds like a good idea, until you figure out that the initramfs doesn't fit in /boot anymore (kernels are ~3-4MB each, so 25MB is plenty, eh?) and you need to either repartition or boot from USB. And since there was no visible failure mode for us before, of course some of us are very confused why a reasonable and effective feature got pruned without replacement. Just because somewhere else it didn't work 100% - that's no reason to remove features for everyone! > >>> 2. Many of Gentoo users are programmers who appreciate the 'vanilla' >>> API experience Gentoo often provides. Switching the defaults to a fork >>> that is known to intentionally diverge from upstream goes against that >>> principle. Programs written against eudev may not work correctly with >>> upstream udev. >> If upstream udev were stable, that would be one thing, but it >> intentionally diverges from itself continuously. The only experience >> that could be reliably provided with upstream udev is one of continual >> breakage. > This is FUD, without any proof. See your reply to (3) - you disagree with yourself! >>> 3. eudev has fallen behind systemd/udev more than once in the past, >>> and caused visible breakage to users this way. >> When? > Whenever we installed new systemd and udev versions, and needed to bump > the dependency in virtual, and eudev maintainers were nowhere to be > found. Which was only needed due to API changes and/or feature removal. Which is exactly what you claimed didn't happen, so go FUD yourself :) > >> Can we also consider all of the times udev broke the boot process >> because upstream just didn't care about doing changes in a sane way and >> the people interested in providing the upstream experience delivered on >> that goal? > Proof needed. "Persistent network naming" caused me at least three independent boot failures - (1) network device got renamed away from eth0 by default. That's horrible, why would you change the default like this?! (If it were an option that I had to consciously turn on it'd be great) (2) persistent naming only triggers when net link status is up. Thus if the switch takes more time than the server (which it did) the renaming did *not* happen, init script looks for en3p7 or whatever but now it's eth0 again. This means I can't automatically power on systems after power failure ... (3) race condition in persistent naming renames on average 2 out of 4 of the interfaces on bnx2 / bnx2x quad ethernet cards. So you may have en3p0, eth1, eth2, en3p4 ... or eth0, en3p1, eth3, eth2. The only available fixes for this are *not* using the persistently buggy renamer thingy and instead use either MAC-based naming or pass 'net.ifnames=0' on the kernel command line to keep the stable kernel names. At my current workplace we're stapling it to the MAC address - that way whenever a NIC fails we need to also change udev config, but at least we can guarantee which interface is which. Quite useful for server machines that have between two and six interfaces. And that's independent of the movearounding - see udev init script: bins="/sbin/udevd /lib/systemd/systemd-udevd /usr/lib/systemd/systemd-udevd" I'm not even going to ask why a binary is in /lib when it used to live in /sbin. (And I will not point out the wrongness of config in /lib, because apparently people get upset when the madness is pointed out ... ) > >>> 4. eudev is underdocumented, and the maintainer admits that 'he sucks >>> at documenting'. In fact, did anyone even bother to note how far eudev >>> diverges from upstream udev to this point? >> The FreeBSD developers were complaining about how poorly documented udev >> was well before eudev existed. This is not a regression unless systemd's >> innovations in replacing documented things with undocumented things made >> them worse. > So... replacing thing that has some docs with a thing that has no docs > and links to docs of udev that aren't exact match for eudev is good? > Good to know. > Having tried to use the systemd 'documentation' - that's actually progress, having no documentation is better than a random pile of braindumps. "Read the source", as usual ...
