Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Fwd: [gentoo-dev] eudev project announcement
Date: Sat, 15 Dec 2012 12:35:43
Message-Id: CA+czFiB3025gjo+rf-LZV+hnhiiP-anocXaYpQC5uJRA26c_nw@mail.gmail.com
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

Attachments

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