If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Say that newer kernel introduces the possibility of some new features when it comes to how modules/firmwares are handled, and you want your system to make use of them.
Then according to that letter you quoted you either have to start using systemd-udev (that is systemd and their version of udev), or fork udev.
This since the standalone-version of udev you can build from the systemd sources will, according to your quote, not receive polishing nor new features.

Say that newer kernel introduces the possibility of some new features when it comes to how modules/firmwares are handled, and you want your system to make use of them.
Then according to that letter you quoted you either have to start using systemd-udev (that is systemd and their version of udev), or fork udev.
This since the standalone-version of udev you can build from the systemd sources will, according to your quote, not receive polishing nor new features.

See the problem with that?

I see the problem with assumptions possibilities ifs and whens. So in your case until the kernel introduces features that require a fork i don't see the need for one. But of course they are free to do whatever they want and fork whatever. In the same way people are free to built shelters because the end of the world (or the E17 release ) is coming on the 21st.

So if I understand this right in systemd-devs pov if you wanted to use only udev you have to compile whole systemd at the same time. This would be ok binary distros like ubuntu and tho upstart, but not in source distros like gentoo. If I would want to use only udev with gentoo I don't want to compile something that are not needed, it's just a waste of time and resources of my own computer. And what Hubbs suggested with his patches is to add two configure flags that make possible to compile only udev.

So if I understand this right in systemd-devs pov if you wanted to use only udev you have to compile whole systemd at the same time. This would be ok binary distros like ubuntu and tho upstart, but not in source distros like gentoo. If I would want to use only udev with gentoo I don't want to compile something that are not needed, it's just a waste of time and resources of my own computer. And what Hubbs suggested with his patches is to add two configure flags that make possible to compile only udev.

For what it is worth, Koen tried yesterday to upstream a patch that I wrote to restore support for older kernels, but it was rejected. Kay Sievers wrote a longer email than what I quote here, but here is an abridged version:

We generally do not want to work around kernel or libc "bugs". So I'm
not interested in such a patch.

People who want or need to play these match-and-mix games with "new
userspace on old systems" should fix the dependencies where they are
missing, not expect "magic" workarounds from tools. There are many
subtle dependencies on various things which are not available on old
kernels and libc, this is just a very obvious one. We should not
pretend we support that model, we just don't. And it will get even
harder in the future, as we are trying to build a real OS now not a
"bag of bits".

The two projects have orthogonal priorities. eudev favors long term compatibility as a modular component while systemd favors the single tree approach where support for older versions of components is pointless. Both have merits.

For what it is worth, Koen tried yesterday to upstream a patch that I wrote to restore support for older kernels, but it was rejected. Kay Sievers wrote a longer email than what I quote here, but here is an abridged version:http://lists.freedesktop.org/archive...er/007763.html

To complete the version:

We surely will not make anything harder than it needs to be, but
pretending bleeding edge tools will or should work on 2 years old
kernels is a promise we do not want to make with systemd/udev. In this
case, it would be the job of the libc, not the user of libc.

We surely support things the other way around, what the kernel is
doing, which is new kernels on old systems, but doing it both ways is
not really the goal for us.

Is that what eudev was all about? Running newer udev on very old kernel release?