[arch-dev-public] Udev 145, signalfd(), and glibc with older kernels
allan at archlinux.org
Mon Aug 10 21:34:28 EDT 2009
Dan McGee wrote:
> On Mon, Aug 10, 2009 at 6:06 PM, Jan de Groot<jan at 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
>>> Long story short- if we apply this patch
>>> from the Debian patch collection, 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?
>>>  Other Debian patches:
>> 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:
There is still no real formal approach to handling glibc maintenance
releases upstream but I do not see this committed to any of the
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.
More information about the arch-dev-public