Follow Slashdot stories on Twitter


Forgot your password?
Open Source Linux

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.
This discussion has been archived. No new comments can be posted.

Gentoo Developers Fork udev

Comments Filter:
  • Re:What is udev? (Score:3, Informative)

    by Anonymous Coward on Friday November 16, 2012 @05:17PM (#42006021)
    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*
  • by Anonymous Coward on Friday November 16, 2012 @05:23PM (#42006113)

    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.

  • by semi-extrinsic ( 1997002 ) <asmunder.stud@ntnu@no> on Friday November 16, 2012 @05:29PM (#42006185)
    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!"
  • by Anonymous Coward on Friday November 16, 2012 @05:55PM (#42006529)

    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.

  • by LordLimecat ( 1103839 ) on Friday November 16, 2012 @05:57PM (#42006555)

    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.

  • by Chirs ( 87576 ) on Friday November 16, 2012 @07:29PM (#42007747)

    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.

  • by Carnildo ( 712617 ) on Friday November 16, 2012 @09:50PM (#42009091) Homepage Journal

    Why? Doesn't the system need some sort of root fs to boot? I am asking out of ignorance and curiosity, nothing else.

    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.

  • by m6tt ( 263581 ) on Friday November 16, 2012 @11:17PM (#42009557)

    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?

  • by Rich0 ( 548339 ) on Saturday November 17, 2012 @07:59AM (#42011275) Homepage

    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.

  • by colin_s_guthrie ( 929758 ) on Monday November 19, 2012 @06:08AM (#42025341) Homepage

    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!

All laws are simulations of reality. -- John C. Lilly