Op 19 dec. 2012, om 06:20 heeft microcai <[email protected]> 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 <[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? 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
