Dan McGee wrote:
On Mon, Aug 10, 2009 at 6:06 PM, Jan de Groot<j...@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/any/cvs-signalfd-eventfd.diff)
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.
And here is the actual commit:
http://repo.or.cz/w/glibc.git?a=commitdiff;h=aa7492d2
There is still no real formal approach to handling glibc maintenance
releases upstream but I do not see this committed to any of the
unofficial ones...
I was going to pull the "release/2.10/master" branch which is a good
base for a glibc maintenance release (somewhat similar to the Suse
version), possibly with some of the extra commits pulled in by Fedora on
their fedora/glibc-2.10.1-4 branch, and update glibc some time this
week. I have no issues with adding this additional patch.
Allan
