1 |
On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote |
2 |
|
3 |
> But, along those lines, what is the goal of the fork? What are you |
4 |
> trying to attempt to do with a fork of udev that could not be |
5 |
> accomplished by: |
6 |
> - getting patches approved upstream |
7 |
> or: |
8 |
> - keeping a simple set of patches outside of the upstream tree and |
9 |
> applying them to each release |
10 |
|
11 |
That approach would be viable if upstream were co-operative or gave a |
12 |
damn about anybody else. They've broken people's sytems with the "new |
13 |
and improved" udev, and claimed that people's systems were already |
14 |
broken. Kay Sievers got Linus angry enough to go on a rant. See |
15 |
https://lkml.org/lkml/2012/10/3/484 |
16 |
|
17 |
> So now, after you've dismissed the patch that did the equivalent |
18 |
> fix in udev (Ming Lei's patch basically disabled your idiotic and |
19 |
> wrong sequence number test for firmware loading), you say it's ok |
20 |
> to bypass udev entirely, because that is "more robust". |
21 |
> |
22 |
> Kay, you are so full of sh*t that it's not funny. You're refusing |
23 |
> to acknowledge your bugs, you refuse to fix them even when a patch |
24 |
> is sent to you, and then you make excuses for the fact that we have |
25 |
> to work around *your* bugs, and say that we should have done so from |
26 |
> the very beginning. |
27 |
> |
28 |
> Yes, doing it in the kernel is "more robust". But don't play games, |
29 |
> and stop the lying. It's more robust because we have maintainers that |
30 |
> care, and because we know that regressions are not something we can |
31 |
> play fast and loose with. If something breaks, and we don't know what |
32 |
> the right fix for that breakage is, we *revert* the thing that broke. |
33 |
> |
34 |
> So yes, we're clearly better off doing it in the kernel. |
35 |
> |
36 |
> Not because firmware loading cannot be done in user space. But simply |
37 |
> because udev maintenance since Greg gave it up has gone downhill. |
38 |
|
39 |
And as for Gentoo expecting co-operation, see Lennart's attitude |
40 |
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/023434.html |
41 |
> If you don't do RT development or doing |
42 |
> RT development only for embedded cases, or if you are a |
43 |
> Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy |
44 |
> then it doesn't mean anything for you. |
45 |
|
46 |
In short, the systemd-udev people are hard to work with in general, |
47 |
and have a dislike for Gentoo. Good luck with getting patches accepted |
48 |
by them. |
49 |
|
50 |
> Oh, and if _anyone_ thinks that changing udev is going to "solve" the |
51 |
> "no separate /usr without an initrd" issue, I have a bridge I want to |
52 |
> sell them. |
53 |
|
54 |
If udev-systemd merely broke a filesystem layout that functioned very |
55 |
well in linux for 2 decades, you would not be seeing this rebellion. |
56 |
udev-systemd is also breaking media drivers. The entire thread |
57 |
https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay |
58 |
has screwed up udev. You participated in that thread. |
59 |
|
60 |
> I understand the bizarre need of some people to want to build the udev |
61 |
> binary without the build-time dependencies that systemd requires, but |
62 |
> surely that is a set of simple Makefile patches, right? |
63 |
|
64 |
Wrong. You're assuming that Sievers/Poettering would allow that. |
65 |
They've made no secret of their disdain of standalone udev. Everybody |
66 |
has seen Poettering's post... |
67 |
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html |
68 |
> (Yes, udev on non-systemd systems is in our eyes a dead end, in case |
69 |
> you haven't noticed it yet. I am looking forward to the day when we |
70 |
> can drop that support entirely.) |
71 |
|
72 |
How many people have read Siever's post? |
73 |
http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html |
74 |
> We promised to keep udev properly *running* as standalone, we never |
75 |
> told that it can be *build* standalone. And that still stands. |
76 |
> |
77 |
> We never claimed, that all the surrounding things like documentation |
78 |
> always fully match, if only udev is picked out of systemd. |
79 |
> |
80 |
> I would welcome if people stop reading that "promise" into the |
81 |
> announcement, it just wasn't written there. |
82 |
|
83 |
You (the former udev maintainer) are saying that a standalone udev |
84 |
*WITHOUT SYSTEMD* will always be possible. The current maintainer is |
85 |
saying that isn't necessarily true. Who do you expect me to believe? |
86 |
|
87 |
You also wrote... |
88 |
|
89 |
> And is something that small really worth ripping tons of code out of |
90 |
> a working udev, causing major regressions on people's boxes (and yes, |
91 |
> it is a regression to slow my boot time down and cause hundreds of |
92 |
> more processes to be spawned before booting is finished.) |
93 |
|
94 |
Some people are finding firmware drivers not loading, and the cards |
95 |
not functioning. Don't you consider that a regression? Seiver's |
96 |
response is basically the same as for people with separate /usr; telling |
97 |
them that they have to re-write their drivers to accomadate the "new and |
98 |
improved" udev. And people whose drivers don't fail entirely now get a |
99 |
60-second delay while udev times out before loading the firmware in |
100 |
another manner. Those people have seen their bootup times increased by |
101 |
a full minute. Do you not consider that a regression? |
102 |
|
103 |
> As I posted elsewhere, working on a project based on "hate" only lasts |
104 |
> so long. I should know, that's the reason I started udev in the first |
105 |
> place over 9 years ago. |
106 |
|
107 |
The Xfree86 people generated a lot of hate, just like Sievers and |
108 |
Poettering. Xorg hasn't burned out yet. |
109 |
|
110 |
> You need to have a real solid goal in place in order to be able to keep |
111 |
> this up in the long-run. Otherwise you are going to burn yourself out, |
112 |
> and end up alienating a lot of people along the way. |
113 |
|
114 |
Howsabout a standalone udev, with no dependancies on systemd, and it |
115 |
won't break people's systems? |
116 |
|
117 |
-- |
118 |
Walter Dnes <waltdnes@××××××××.org> |
119 |
We are apparently better off trying to avoid udev like the plague. |
120 |
Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349 |