On 2012年12月17日星期一 CST下午10时36分48秒, Kay Sievers wrote:
On Mon, Dec 17, 2012 at 2:04 PM, Koen Kooi
<[email protected]> wrote:
Op 17 dec. 2012, om 12:17 heeft Zbigniew Jędrzejewski-Szmek
<[email protected]> 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
