From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C5CC11381F3 for ; Sat, 15 Dec 2012 21:02:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5CDA021C0A5 for ; Sat, 15 Dec 2012 21:02:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 04D9F21C0CD for ; Sat, 15 Dec 2012 20:33:37 +0000 (UTC) Received: from [10.177.176.234] (212-226-40-113-nat.elisa-mobile.fi [212.226.40.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id 7608733DC59 for ; Sat, 15 Dec 2012 20:33:36 +0000 (UTC) Message-ID: <50CCDE98.5050809@gentoo.org> Date: Sat, 15 Dec 2012 22:33:28 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] eudev project announcement References: <50CBF400.2060104@gentoo.org> In-Reply-To: <50CBF400.2060104@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 6649da7e-89cf-447e-aab7-3e4a74da2435 X-Archives-Hash: 89d6066b1582fd21365dac8171daaa19 On 15/12/12 05:52, Richard Yao wrote: > 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 > Despite what you may have thought or seen my opinions to be earlier, I wish best of luck to you. I don't have plans on trying eudev, and trust you will continue to backport relevent code from orig. upstream git so people don't have to cross-post to 2 different places. I also hope eudev will never require code to other packages, in a way of keeping the compability with orig. upstream to keep things maintainable as they are now. Thanks, Samuli