Slashdot Mirror

← Back to Stories (view on slashdot.org)

Gentoo Developers Fork udev

Posted by Unknown on from the lennart-vows-revenge dept.

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.

2 of 152 comments (clear)

  1. We have not made an official announcement yet by Anonymous Coward · · 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.

  2. not impossible, but breaks existing drivers by Chirs · · 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.