[arch-dev-public] Udev 145, signalfd(), and glibc with older kernels
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
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).
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
Dan McGee wrote:
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.
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
participants (3)
-
Allan McRae
-
Dan McGee
-
Jan de Groot