1 |
On Sun, Nov 18, 2012 at 02:05:39AM -0500, Walter Dnes wrote: |
2 |
> On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote |
3 |
> |
4 |
> > But, along those lines, what is the goal of the fork? What are you |
5 |
> > trying to attempt to do with a fork of udev that could not be |
6 |
> > accomplished by: |
7 |
> > - getting patches approved upstream |
8 |
> > or: |
9 |
> > - keeping a simple set of patches outside of the upstream tree and |
10 |
> > applying them to each release |
11 |
> |
12 |
> That approach would be viable if upstream were co-operative or gave a |
13 |
> damn about anybody else. They've broken people's sytems with the "new |
14 |
> and improved" udev, and claimed that people's systems were already |
15 |
> broken. Kay Sievers got Linus angry enough to go on a rant. See |
16 |
> https://lkml.org/lkml/2012/10/3/484 |
17 |
|
18 |
Yes, I know all about the firmware issue with media drivers. It's now |
19 |
resolved and fixed, in two different ways (the kernel now loads firmware |
20 |
directly, and on older kernels, udev has fixed the issue.) So that's no |
21 |
longer an issue for anyone. |
22 |
|
23 |
> In short, the systemd-udev people are hard to work with in general, |
24 |
> and have a dislike for Gentoo. Good luck with getting patches accepted |
25 |
> by them. |
26 |
|
27 |
The fact that Gentoo is alone in wanting to build udev, without systemd |
28 |
dependencies being on the system, is something that if I were the |
29 |
systemd maintainer, I would reject. It's also a pretty simple set of |
30 |
patches that Gentoo can keep around if it's really a serious issue for |
31 |
people. |
32 |
|
33 |
> > Oh, and if _anyone_ thinks that changing udev is going to "solve" the |
34 |
> > "no separate /usr without an initrd" issue, I have a bridge I want to |
35 |
> > sell them. |
36 |
> |
37 |
> If udev-systemd merely broke a filesystem layout that functioned very |
38 |
> well in linux for 2 decades, you would not be seeing this rebellion. |
39 |
|
40 |
Note, a separate /usr has been broken for a while now, udev is just |
41 |
pointing the issue out. And again, if you want a separate /usr, just |
42 |
use an initrd, the solution is simple. |
43 |
|
44 |
> udev-systemd is also breaking media drivers. The entire thread |
45 |
> https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay |
46 |
> has screwed up udev. You participated in that thread. |
47 |
|
48 |
Again, this is now resolved, no need to keep beating it :) |
49 |
|
50 |
> How many people have read Siever's post? |
51 |
> http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html |
52 |
> > We promised to keep udev properly *running* as standalone, we never |
53 |
> > told that it can be *build* standalone. And that still stands. |
54 |
> > |
55 |
> > We never claimed, that all the surrounding things like documentation |
56 |
> > always fully match, if only udev is picked out of systemd. |
57 |
> > |
58 |
> > I would welcome if people stop reading that "promise" into the |
59 |
> > announcement, it just wasn't written there. |
60 |
> |
61 |
> You (the former udev maintainer) are saying that a standalone udev |
62 |
> *WITHOUT SYSTEMD* will always be possible. The current maintainer is |
63 |
> saying that isn't necessarily true. Who do you expect me to believe? |
64 |
|
65 |
They are saying it as well. It's Gentoo that is unique in wanting to |
66 |
build it without the rest of the systemd package as well. Two different |
67 |
things here. |
68 |
|
69 |
> You also wrote... |
70 |
> |
71 |
> > And is something that small really worth ripping tons of code out of |
72 |
> > a working udev, causing major regressions on people's boxes (and yes, |
73 |
> > it is a regression to slow my boot time down and cause hundreds of |
74 |
> > more processes to be spawned before booting is finished.) |
75 |
> |
76 |
> Some people are finding firmware drivers not loading, and the cards |
77 |
> not functioning. Don't you consider that a regression? |
78 |
|
79 |
Again, been a bug for 6 months, hit by very few people, now resolved, |
80 |
not an issue. |
81 |
|
82 |
> Seiver's response is basically the same as for people with separate |
83 |
> /usr; telling them that they have to re-write their drivers to |
84 |
> accomadate the "new and improved" udev. And people whose drivers |
85 |
> don't fail entirely now get a 60-second delay while udev times out |
86 |
> before loading the firmware in another manner. Those people have seen |
87 |
> their bootup times increased by a full minute. Do you not consider |
88 |
> that a regression? |
89 |
|
90 |
Again, now resolved, not an issue. |
91 |
|
92 |
> > You need to have a real solid goal in place in order to be able to keep |
93 |
> > this up in the long-run. Otherwise you are going to burn yourself out, |
94 |
> > and end up alienating a lot of people along the way. |
95 |
> |
96 |
> Howsabout a standalone udev, with no dependancies on systemd, and it |
97 |
> won't break people's systems? |
98 |
|
99 |
If that is the goal, great, it would be wonderful if someone would say |
100 |
that. But from looking at the commits so far in the repo, it really |
101 |
doesn't look like that is the goal. Or if it is, it's getting there in |
102 |
a very odd way. |
103 |
|
104 |
thanks, |
105 |
|
106 |
greg k-h |