Gentoo Developers Fork udev 152
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.
Re:What is udev? (Score:3, Informative)
We have not made an official announcement yet (Score:5, Informative)
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.
So that's why my system would hang at boot (Score:5, Informative)
Re:Thumbs down on the name (Score:2, Informative)
That's not a nice way to treat a project that you've used up to now. Udev isn't gone or obsolete. A fork isn't "-ng". Compete on merit, not marketing.
Being a fairly happy Gentoo user for numerous years now (posting AC to avoid the inevitable derisive sneers), that's pretty much how Gentoo's naming scheme goes. If they have a major fork of something, it'll get the -ng suffix on it until they come up with a better name (usually; sometimes the -ng name just sticks). It's not a declaration of obsolescence, it's just a naming convention.
Re:Thumbs down on the name (Score:4, Informative)
It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report [redhat.com] 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.
not impossible, but breaks existing drivers (Score:5, Informative)
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.
Re:Systemd. Still the root of all ... Stupidity (Score:4, Informative)
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.
Re:We have not made an official announcement yet (Score:3, Informative)
Works great...we even have non-udevd based automount, with custom mount flags...does that still require hacking and a recompile?
How's pulseaudio working out for you?
Re:Systemd. Still the root of all ... Stupidity (Score:4, Informative)
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.
Re: Yes Lennart Realy is that Loony (Score:3, Informative)
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!