Re: [gentoo-dev] Changing order of default virtual/udev provider

[Michał Górny]

Dnia 17 lutego 2016 09:17:37 CET, Patrick Lauer <patrick@g.o> 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)