1 |
Dear Everyone, |
2 |
|
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. |
9 |
|
10 |
Why fork udev? |
11 |
|
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. |
19 |
|
20 |
You are a Gentoo project. What does this mean? |
21 |
|
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. |
33 |
|
34 |
What is your project's license? |
35 |
|
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. |
40 |
|
41 |
What are your project's goals? |
42 |
|
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. |
50 |
|
51 |
How will you minimize regressions? |
52 |
|
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. |
62 |
|
63 |
How do you intend to work with other distributions? |
64 |
|
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. |
76 |
|
77 |
Will you make the boot process faster? |
78 |
|
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. |
96 |
|
97 |
What did systemd break when trying to make things faster? |
98 |
|
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. |
125 |
|
126 |
Where is development now? |
127 |
|
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. |
139 |
|
140 |
What are your plans for future development? |
141 |
|
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. |
150 |
|
151 |
Yours truly, |
152 |
Richard Yao |
153 |
|
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: |
159 |
|
160 |
http://www.gentoo.org/main/en/lists.xml |