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