The eudev project launches

From: Richard Yao <ryao-AT-gentoo.org> To: gentoo-dev-announce+subscribe-AT-lists.gentoo.org Subject: eudev project announcement Date: Fri, 14 Dec 2012 22:52:32 -0500 Message-ID: <50CBF400.2060104@gentoo.org> Cc: "gentoo-dev-AT-lists.gentoo.org" <gentoo-dev-AT-lists.gentoo.org>, gentoo-project-AT-lists.gentoo.org Archive-link: Article, Thread

Dear Everyone, I am pleased to announce the Gentoo eudev project. Many of you already know about the eudev project from early publicity that we had before things were ready. Despite that, I hope to take advantage of the official announcement to explain what we are doing, why we are doing it and what it means for you. I have broken the announcement into subsections, each with a title for ease of reading. Why fork udev? Earlier this year, udev upstream was absorbed into systemd. udev often breaks compatibility with older systems by depending upon recent Linux kernel releases, even when such dependencies are avoidable. This became worse after udev became part of systemd, which has jeopardized our ability to support existing installations. The systemd developers are uninterested in providing full support in udev to systemd alternatives. These are problems for us and we have decided to fork udev to address them. You are a Gentoo project. What does this mean? Gentoo as an organization is quite similar to github, although it is exclusive to Gentoo developers. Our rules permit all Gentoo developers have the ability to start a project and such projects are entitled to be hosted on Gentoo infrastructure. This by no means constitutes official endorsement by Gentoo's governing body and we have no authority to dictate the future direction of Gentoo. We do have the ability to provide an alternative to Gentoo users, which we fully intend to do. eudev will be by no means exclusive to Gentoo. We will handle bug reports from users of other distribution in the same way that we handle bug reports involving Gentoo. This will be much like other Gentoo-hosted projects such as portage and OpenRC. What is your project's license? The systemd developers were in the middle of a transition to the LGPL from the GPL when we forked. We inherited the code in the middle of that transition and we see no reason to pursue a different course. Therefore, all future changes that we make to eudev will be available under the LGPL. What are your project's goals? Our primary goal is to address the problems with systemd-udev that caused us to fork it in the first place. In particular, we want better compatibility with existing software such as OpenRC and Upstart, older kernels, various toolchains and anything else required by users and various distributions. We also want to minimize regressions and work with developers of other distributions (and components used by them) to address issues. How will you minimize regressions? We intend to maintain HEAD in a releaseable state. All minor changes require review from one eudev developer and all major changes require review from two eudev developers. This does not include the author. In addition, we intend to require commits to make logically independent changes with descriptive commit messages to make regression hunting easier when regressions do happen. These rules were not enforced at the beginning, but we are transitioning toward enforcement. They will enter full effect once we tag our first release candidate. How do you intend to work with other distributions? We have our repository on github, which is known for easy collaboration. If a distribution developer identifies a problem with eudev, they can file an issue and we will do our best to resolve their problem. If they wish to work with us to resolve it, we can talk in IRC and they can also file pull requests. Provided that the changes are not entirely unreasonable (e.g. pushing an init system into udev), we are willing to work with authors of pull requests to get them into a mergeable state. The only hard rule is that changes cannot break the ability of existing systems to upgrade. We also plan to make an official mailing list, which will be hosted on Gentoo infrastructure. Will you make the boot process faster? We have ideas on how to make udevd faster. However, people usually only notice the time that udevd takes when there is a bug and we are more interested in fixing those bugs than we are in shaving milliseconds off boot time. There are plenty of areas that could use attention by people that are interested in a faster boot process before udev becomes one of them. We consider things such as a reliable boot process to be more important than speed and we are willing to subject users to the additional few hundred milliseconds that failing to tweak things for speed incurs. We are already dealing with regressions that the systemd developers introduced in their attempt to make things faster and we consider fixing them to be a priority. However, we would be happy to collaborate with people willing to work on boot speed improvements to get them into a mergeable state. We encourage people interested in speed improvements to talk to us about how they could be done in a reasonable manner. It would be premature to do it at this instant, but it would definitely be something that could be done after we have tagged a few stable releases. What did systemd break when trying to make things faster? A good example involves module loading. Previously, each module load would incur a roughly 10 to 20 ms disk access latency and a 0.01 ms fork overhead. This was partially masked by udev's ability to execute rules asynchronously through fork(), which meant that multiple modules could be read in parallel. The introduction of kmod eliminated the 0.01 ms fork() overhead, and consequently required each module to be loaded sequentially. This imposes an overhead of 10 to 20 milliseconds times the number of modules, which is asymptotically worse than what it replaced. A feature of kmod intended to address that placed all modules into a single file, which would actually make things faster. However, none of our users use it and all of our users would suffer from it. In addition, the manner in which kmod was integrated has implications beyond speed regressions. The use of kmod by udev permits a buggy kernel module (possibly interacting with bad hardware) to hang in module_init. This causes udevd to hang, which prevents further rule processing. This is a bad situation, but we feel that it is important to handle bad situations in a graceful manner. Previously, the system would have a chance of booting in this situation. The manner in which kmod was introduced makes this situation far more likely to cripple systems. If you want to understand the worst case scenario when dealing with this regression, disable udev and reboot your system. You should have a virtual terminal with no networking and no X. Should this happen with systemd-udevd, then you would also have a hung systemd-udevd process that you cannot kill. Attempts restart systemd-udevd should result in more hung processes. Where is development now? We have rewritten the build system and restored support for older kernels and verified compatibility as far back as Linux 2.6.31. We have tagged 1_beta1 and eudev is in the portage tree. A few lingering dependency issues exist, but we should have them ironed out shortly. Work is on-going to introduce uclibc support, to reintroduce 70-persistent-net.rules and to reintroduce support for a separate /usr support without an initramfs. Strictly speaking, we do not recommend having a separate /usr mount, but we intend to support such configurations in eudev indefinitely. We are also looking into fixing various regressions that the systemd developers introduced, which include the kmod regressions. What are your plans for future development? We intend to demonstrate to the current Gentoo udev maintainers that maintaining systemd-udevd outside of the systemd package is unnecessary when we have eudev. If they wish to continue maintaining systemd-udevd as they are, then that is fine unless the Gentoo Council decides otherwise. After eudev has reached stable status in Gentoo, we intend to start reaching out to other distributions to collaborate on further development. Ideally, eudev will be something that all distributions can use as a drop-in replacement for systemd-udevd. Yours truly, Richard Yao P.S. I have BCCed a few people that might be interested in reading the project announcement. Unfortunately, the gentoo-dev list requires registration to avoid spammers, so you will need to register to reply to the list. Documentation on how to register on the list is available at the following address: http://www.gentoo.org/main/en/lists.xml