[systemd-devel] eudev fork and patches there

[Kay Sievers]

On Mon, Dec 17, 2012 at 2:04 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
> Op 17 dec. 2012, om 12:17 heeft Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> het volgende geschreven:

>> eudev has made a project annoucement [1], and I thought it would be
>> worthwhile to go through their patches and cherry-pick. I've now done
>> that (until cc5c144a70fc37e 'Merge pull request #32') and the results
>> regarding patches which can be used directly are not very impressive:
>> one patch to fix clang warnings. There are quite a few
>> build/compiler-warning in their tree, but they just seem to be fixes
>> for problems introduced with their changes.
>>
>> Potentially usefull would also be the patch c189ab 'Fix unused result
>> warnings', but it would be good if somebody familar with the code took
>> a look if it is enough to print warnings (or even if they should be
>> printed) or some more definite action should be taken.
>>
>> Also potentially usefull are the changes to allow 'make distcheck'
>> without gtk-doc, but they are spread out over multiple commits in a
>> messy way, so could only be used as inspiration.
>>
>> There's also nice patch bfc850 'Add fallback path when accept4() is
>> not available.' Do we care about kernels < 2.6.28? (This version is
>> according to man accept4(2), patch text mentions different versions.)
>
> Keep in mind that your *libc has to support accept4() as well. I ran into that problem a long time ago [1]. Backporting support for accept4() is trivial. For systemd you'll need 2 more backports: cgroup mountpoint and the active terminal thing.
> Also note that epoll() was added to non-x86 architectures a lot later than x86.

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".

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.

Thanks,
Kay