Dnia 17 lutego 2016 09:17:37 CET, Patrick Lauer <patr...@gentoo.org> napisał(a): >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.
So, to summarize. Random non-repeatable behavior is good. Having repeatable boots is bad and exciting. Because then you can't claim your bugs are not bugs, right? > >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 ... ) The wrongness is relying on any particular location of a daemon. The init system setup needs to know where it is, and that should go along with a package that installs it. Of course, it falls apart if you split scripts apart, then force movearounding to suit your fancy love to the past. >> >>>> 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 ... -- Best regards, Michał Górny (by phone)
