[systemd-devel] eudev fork and patches there

[Koen Kooi]

Op 19 dec. 2012, om 06:20 heeft microcai <microcai at fedoraproject.org> het volgende geschreven:

> On 2012年12月17日星期一 CST下午10时36分48秒, Kay Sievers wrote:
>> 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.
> 
> agree. people should just upgrade their kernel. does kernel really remove old hardware support? if not, then why are we stick to old kernels?

I get stuck on older kernels when the (silicon)vendor only has support for their chip/board in their vendor kernel, not in mainline. 

regards,

Koen