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