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