On Mon, Aug 10, 2009 at 6:06 PM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Mon, 2009-08-10 at 15:32 -0500, Dan McGee wrote:
So as has been brought up in other threads, udev 145 uses signalfd(), which unfortunately seems to be absent in older kernels. That is only half the story.
From this Debian bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537509), glibc 2.9 and later unfortunately broke compatibility with the older signalfd and eventfd syscalls that are present in all kernels after 2.6.22. A new syscall (signalfd4) was introduced in 2.6.27, and for some reason glibc decided to completely switch to this rather than be backwards-compatible.
Long story short- if we apply this patch (http://patch-tracking.debian.net/patch/series/dl/eglibc/2.9-23+multiarch.2/a...) from the Debian patch collection[1], we can make our glibc, and thus udev, compatible with modern-ish kernels out there and not cause unnecessary breakage for users. It should have nearly zero impact for anyone else as glibc will still prefer the new syscall.
Anyone, glibc maintainer, objections or thoughts?
-Dan
[1] Other Debian patches: http://patch-tracking.debian.net/package/eglibc/2.9-23+multiarch.2
Yes, we need this. Debian has applied it already, so we're not alone with this. This will reduce breakage a lot. Our minimal kernel for udev will be 2.6.22 then, which sounds a lot better than 2.6.25 minimum (and possibly 2.6.27 minimum if I believe the Debian bugreport).
The Debian bug report doesn't lie; the new signalfd() interface isn't present until 2.6.27 which is all our glibc can use. That is only a ~8 month old kernel at best, which is not all that kind to anyone with a long uptime (e.g. gerolde). And as a side note, Ulrich Drepper wrote this patch, so it can't be that sketchy. Obviously we need Allan on board with this being the current Arch glibc maintainer. :) -Dan