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
>>>>> since at least 2012
>>>>> (see for example:
>>>>> https://lkml.org/lkml/2012/10/3/618
>>>>> )
>>>>> So it'd be (1) following upstreams recommendations and (2)
>>>>> 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.
>>>> is more likely to break because of the Gentoo developer(s) working
>>>> to merge upstream changes to their incompatible code.  
>>> That was the entire point of the project. Upstream rejected any
>>> to do things that we actually needed and broke things claiming the
>>> distributions were responsible for handling the breakage, so eudev
>>> 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
>> 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

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, 

>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
>(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
>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
>>>> API experience Gentoo often provides. Switching the defaults to a
>>>> that is known to intentionally diverge from upstream goes against
>>>> principle. Programs written against eudev may not work correctly
>>>> 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
>>> 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
>> 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
>>> the people interested in providing the upstream experience delivered
>>> 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
>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
>renamer thingy and instead use either MAC-based naming or pass
>'net.ifnames=0' on the kernel command line to keep the stable kernel
>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
>can guarantee which interface is which. Quite useful for server
>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
>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
>>>> at documenting'. In fact, did anyone even bother to note how far
>>>> diverges from upstream udev to this point?  
>>> The FreeBSD developers were complaining about how poorly documented
>>> was well before eudev existed. This is not a regression unless
>>> innovations in replacing documented things with undocumented things
>>> them worse.
>> So... replacing thing that has some docs with a thing that has no
>> 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)

Reply via email to