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.
You may want to look into this unix idea of "modularity." The idea is that things in your system specialize and be very good at a few things. Then later you can replace them if necessary. *pats head*
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.
I had this problem with my eeepc 1215b hanging 30 sec at boot. Spent half a day fixing it, didn't understand why the fix worked. At the time i cursed Broadcom, but it was intentionally done by udev? Wtf?? I say "Forks away!"
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
In other news, in response to the recent creation of the udev-ng fork, Lennart Poettering has announced that udev maintainers are renaming their project to uPulseDevKitd in order to better reflect its capabilities.
Well, at least there's one distro that's tired of letting Red Hat developers dictate the course of linux component development and marginalize the whole independent distro model. Hello Debian? Ubuntu? SuSE? Are you guys beginning to see a pattern here?
It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report on the issue:
[dev gives reasons why it is impossible to probe for drivers to load prior to loading some pieces of firmware]
All that doesn't matter; do whatever you need to do, but load the firmware
async, and continue to do the rest of the job when the firmware arrives, and
do not block modprobe.
Unless Im misreading that, Kay is saying "i dont care that the thing Im asking you to do is impossible, just do i t anyways, because its more correct".
Im not a software dev, so maybe Im misreading this, but everyone seems to agree that what the udev folks are mandating is simply impossible in many instances.
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
Why don't you just call it udev.
I like systemd, logind, and journald. But I take serious issue with the fact that they're pulling all of these logically distinct things into the same repository. There's no difference with udev. The innovation is good, but what happened to the Unix philosophy?
Udev should never have been pulled into the same source tree. If there was a lot of code overlap, then it should have been put into a library that both udev and systemd can depend on.
So, forget the -ng. The systemd guys will probably be happy enough calling theirs "systemd-udev" or "udev-systemd"
If you see a project that Lennart Poettering is involved in...............run for the hills. Seriously. There have been many fits of insanity with PulseAudio (something that has set desktop Linux audio back years) and systemd is such a departure from traditional Unix system administration it's just ridiculous. That might not be a completely bad thing is done carefully but this guy is full of his own self-importance and just cannot see the lunatic path he's on. Ulrich Drepper has similar 'issues'.
Seriously, how can you break something so fundamentally that worked for so many years?
.....In the long and broken road to PulseAudio broken Linux drivers are a very recurring theme.................
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.
Is Kay Sievers really that dumb?
Yes and no.
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, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
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.
No, it doesn't. At boot time (specifically, at the point where execution transfers out of the boot ROM (eg. BIOS)), there just needs to be a blob of executable code at a known location in RAM.
For example, I've got a diskless system that netboots: the kernel image gets passed from the netboot server to the client RAM over a TFTP connection; the root filesystem (served over NFS) doesn't show up until a goodly chunk of the kernel has been initialized. As should be obvious, this means I can't use a network card that requires external firmware.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
I'm surprised nobody has suggested the -og suffix.
Don't forget Avahi -- a network-facing daemon included in the default GUI install that has a remote security hole at least once a year. And what it's for? So you can have a link-local chat (compatible only with itself) and some autodetection of rare Apple's printers.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
This whole idiocy is intended to force modules devs to actualy do nothing during init so that udev/systemd can advertise faster boot up times.
Read Linus's arguments. The issue is that apparently certain types of devices drivers that can't be initialized without loading firmware, as it is not possible for them to identify what kind of devices are present/etc otherwise. So, the system can't tell what kinds of devices to create as a result, and then nothing will ever be able to open it anyway.
In theory the idea was a good one, but in practice it didn't really work out, and simply breaking a bunch of devices with no fix possible just isn't acceptable.
Linus wasn't complaining that they should wait forever for driver authors to catch up. He was complaining that it wasn't possible for them to catch up.
I didn't save anything. I just helped out with maintenance and tried to rally the other developers already on board. Lennart's code and knowledge of the audio stuff far, far outweighs my own here. It was Lennart's dogged determination to carry on in the face of unhelpful criticism from the peanut gallery that helped get PulseAudio to its current state of relative stability - including the pushing and poking needed to get the other stuff in the stack fixed too.
Myself and other contributors (more so than me) had a big hand in this too, but credit where credit is due!