[systemd-devel] Re: eudev fork and patches there

[microcai]

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?

for the people insistead on old kernel, they might be using old udev as well. I generally dislike "mixed workarround", that is, new kernel try to workarround old buggy userspace tools and new user space tools workarround buggy old kernels. This also apply to any lib and app.

why dont we just upgrade both and make both life (kernel side and userspace side) more easier ? 

>
> Thanks,
> Kay
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>