Gentoo Archives: gentoo-dev-announce

From: Richard Yao <ryao@g.o>
To: gentoo-dev-announce@l.g.o
Subject: [gentoo-dev-announce] Fwd: eudev project announcement
Date: Sat, 15 Dec 2012 06:09:22
1 Dear Everyone,
3 I am pleased to announce the Gentoo eudev project. Many of you already
4 know about the eudev project from early publicity that we had before
5 things were ready. Despite that, I hope to take advantage of the
6 official announcement to explain what we are doing, why we are doing it
7 and what it means for you. I have broken the announcement into
8 subsections, each with a title for ease of reading.
10 Why fork udev?
12 Earlier this year, udev upstream was absorbed into systemd. udev often
13 breaks compatibility with older systems by depending upon recent Linux
14 kernel releases, even when such dependencies are avoidable. This became
15 worse after udev became part of systemd, which has jeopardized our
16 ability to support existing installations. The systemd developers are
17 uninterested in providing full support in udev to systemd alternatives.
18 These are problems for us and we have decided to fork udev to address them.
20 You are a Gentoo project. What does this mean?
22 Gentoo as an organization is quite similar to github, although it is
23 exclusive to Gentoo developers. Our rules permit all Gentoo developers
24 have the ability to start a project and such projects are entitled to be
25 hosted on Gentoo infrastructure. This by no means constitutes official
26 endorsement by Gentoo's governing body and we have no authority to
27 dictate the future direction of Gentoo. We do have the ability to
28 provide an alternative to Gentoo users, which we fully intend to do.
29 eudev will be by no means exclusive to Gentoo. We will handle bug
30 reports from users of other distribution in the same way that we handle
31 bug reports involving Gentoo. This will be much like other Gentoo-hosted
32 projects such as portage and OpenRC.
34 What is your project's license?
36 The systemd developers were in the middle of a transition to the LGPL
37 from the GPL when we forked. We inherited the code in the middle of that
38 transition and we see no reason to pursue a different course. Therefore,
39 all future changes that we make to eudev will be available under the LGPL.
41 What are your project's goals?
43 Our primary goal is to address the problems with systemd-udev that
44 caused us to fork it in the first place. In particular, we want better
45 compatibility with existing software such as OpenRC and Upstart, older
46 kernels, various toolchains and anything else required by users and
47 various distributions. We also want to minimize regressions and work
48 with developers of other distributions (and components used by them) to
49 address issues.
51 How will you minimize regressions?
53 We intend to maintain HEAD in a releaseable state. All minor changes
54 require review from one eudev developer and all major changes require
55 review from two eudev developers. This does not include the author. In
56 addition, we intend to require commits to make logically independent
57 changes with descriptive commit messages to make regression hunting
58 easier when regressions do happen.
59 These rules were not enforced at the beginning, but we are
60 transitioning toward enforcement. They will enter full effect once we
61 tag our first release candidate.
63 How do you intend to work with other distributions?
65 We have our repository on github, which is known for easy
66 collaboration. If a distribution developer identifies a problem with
67 eudev, they can file an issue and we will do our best to resolve their
68 problem. If they wish to work with us to resolve it, we can talk in IRC
69 and they can also file pull requests. Provided that the changes are not
70 entirely unreasonable (e.g. pushing an init system into udev), we are
71 willing to work with authors of pull requests to get them into a
72 mergeable state. The only hard rule is that changes cannot break the
73 ability of existing systems to upgrade.
74 We also plan to make an official mailing list, which will be hosted on
75 Gentoo infrastructure.
77 Will you make the boot process faster?
79 We have ideas on how to make udevd faster. However, people usually only
80 notice the time that udevd takes when there is a bug and we are more
81 interested in fixing those bugs than we are in shaving milliseconds off
82 boot time. There are plenty of areas that could use attention by people
83 that are interested in a faster boot process before udev becomes one of
84 them. We consider things such as a reliable boot process to be more
85 important than speed and we are willing to subject users to the
86 additional few hundred milliseconds that failing to tweak things for
87 speed incurs.
88 We are already dealing with regressions that the systemd developers
89 introduced in their attempt to make things faster and we consider fixing
90 them to be a priority. However, we would be happy to collaborate with
91 people willing to work on boot speed improvements to get them into a
92 mergeable state. We encourage people interested in speed improvements to
93 talk to us about how they could be done in a reasonable manner. It would
94 be premature to do it at this instant, but it would definitely be
95 something that could be done after we have tagged a few stable releases.
97 What did systemd break when trying to make things faster?
99 A good example involves module loading. Previously, each module load
100 would incur a roughly 10 to 20 ms disk access latency and a 0.01 ms fork
101 overhead. This was partially masked by udev's ability to execute rules
102 asynchronously through fork(), which meant that multiple modules could
103 be read in parallel.
104 The introduction of kmod eliminated the 0.01 ms fork() overhead, and
105 consequently required each module to be loaded sequentially. This
106 imposes an overhead of 10 to 20 milliseconds times the number of
107 modules, which is asymptotically worse than what it replaced. A feature
108 of kmod intended to address that placed all modules into a single file,
109 which would actually make things faster. However, none of our users use
110 it and all of our users would suffer from it.
111 In addition, the manner in which kmod was integrated has implications
112 beyond speed regressions. The use of kmod by udev permits a buggy kernel
113 module (possibly interacting with bad hardware) to hang in module_init.
114 This causes udevd to hang, which prevents further rule processing. This
115 is a bad situation, but we feel that it is important to handle bad
116 situations in a graceful manner. Previously, the system would have a
117 chance of booting in this situation. The manner in which kmod was
118 introduced makes this situation far more likely to cripple systems.
119 If you want to understand the worst case scenario when dealing with
120 this regression, disable udev and reboot your system. You should have a
121 virtual terminal with no networking and no X. Should this happen with
122 systemd-udevd, then you would also have a hung systemd-udevd process
123 that you cannot kill. Attempts restart systemd-udevd should result in
124 more hung processes.
126 Where is development now?
128 We have rewritten the build system and restored support for older
129 kernels and verified compatibility as far back as Linux 2.6.31. We have
130 tagged 1_beta1 and eudev is in the portage tree. A few lingering
131 dependency issues exist, but we should have them ironed out shortly.
132 Work is on-going to introduce uclibc support, to reintroduce
133 70-persistent-net.rules and to reintroduce support for a separate /usr
134 support without an initramfs. Strictly speaking, we do not recommend
135 having a separate /usr mount, but we intend to support such
136 configurations in eudev indefinitely.
137 We are also looking into fixing various regressions that the systemd
138 developers introduced, which include the kmod regressions.
140 What are your plans for future development?
142 We intend to demonstrate to the current Gentoo udev maintainers that
143 maintaining systemd-udevd outside of the systemd package is unnecessary
144 when we have eudev. If they wish to continue maintaining systemd-udevd
145 as they are, then that is fine unless the Gentoo Council decides otherwise.
146 After eudev has reached stable status in Gentoo, we intend to start
147 reaching out to other distributions to collaborate on further
148 development. Ideally, eudev will be something that all distributions can
149 use as a drop-in replacement for systemd-udevd.
151 Yours truly,
152 Richard Yao
154 P.S. I have BCCed a few people that might be interested in reading the
155 project announcement. Unfortunately, the gentoo-dev list requires
156 registration to avoid spammers, so you will need to register to reply to
157 the list. Documentation on how to register on the list is available at
158 the following address:


File name MIME type
signature.asc application/pgp-signature