Slashdot Mirror
Gentoo Developers Fork udev
In October, Linus Torvalds expressed concerns that udev was making "...changes
that were known to be problematic, and are pure and utter stupidity." Several Gentoo developers were also concerned about the removal of features and uncooperative nature of udev maintained by the systemd developers, so they've announced a fork: "After speaking with several other Gentoo developers that share Linus'
concerns, I have decided to form a team to fork udev. Our plan is to eliminate the separate /usr requirement from our fork, among other things. We will announce the project later this week."
The project name (for now) is udev-ng, and you can grab the code from Github. Update: 11/16 21:29 GMT by U L : One of the developers commented that this isn't yet an official Gentoo project (but hopefully it will be!). There's also an informative flamewar about the fork on debian-devel.
I doubt anyone will listen to me at this point, but that was not an official announcement. I wrote that email to preempt a policy decision by the Gentoo Council that would have negatively affected the goals of our nascent project. A consequence of doing fully open source development is that with the exception of issues involving the security of our infrastructure, all of our internal emails are public.
Anyway, the official announcement will come later. We are still working on becoming organized. I also probably should register on slashdot.
Nice doesn't enter into it.
I owe no loyalty to crappy implementations simply because I used them before.
Lots of software wanders off the reservation from time to time and needs to be replaced, or forked back to a point in time where it was working well. If the Dev's won't listen to Linus, what other choices are there?
Sig Battery depleted. Reverting to safe mode.
Those idiots are still giving us all grief. Can't we just kick these guys and they're half-assed project to the curb? Systemd was a good idea, but shit implementation and zero admin love. Hell, they are actively admin hostile! Now they plan to Fuck up udev? great.
They didn't just plan it, they DID it.
Linus was on a roll. Read the whole thread:
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days? Is it Lennart/Kai, as part of systemd?
Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.
"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.
The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
Yeah, that bugzilla shows the problem with Kay as a maintainer too,
not willing to own up to problems he caused.
and
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.
Is Kay Sievers really that dumb?
In this projects IRC channel, someone proposed appending a -pg to it, since the point of this fork is to revert udev to what it was before it went insane. I find this prospect quite amusing and hope it picks up.
"A witty saying proves nothing." - Voltaire
I had code in udev for a while, though it's probably been replaced now. (Moved from multithreaded to singlethreaded and made it way faster at the same time.)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
...I'm a (Free)BSD fanboy/fool. There is occasional stupidity (witness the recent replacement of sysinstall with some half-assed, half-baked, incomplete alternative), but usually the core team is sane, and the flamewars don't have two people both arguing from flawed foundations. The obviously *right* thing to do with this whole mess is simple: toss it.
Create a standard place for firmware files, allow it to be configured and overridden easily, make judicious use of symlinks/union mounts. Then, let the drivers do the right thing: Load up, determine if a firmware needs to be squirted in, load it if so, and continue. This idea of some entire subsystem tied to a userland daemon being responsible for loading device firmware is plain absurd. Drivers know how to load their own firmware, and with an extremely simple knob (rc.conf, linux equiv to loader.conf, sysctl, whatever) they will know where to look for it as well.
Somebody, somewhere, smoked some serious shit to come up with this udev/systemd fiasco to begin with.