[gentoo-dev-announce] Fwd: eudev project announcement

[Richard Yao]

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