[arch-dev-public] Udev 145, signalfd(), and glibc with older kernels

[Dan McGee]

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
>> 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.

Obviously we need Allan on board with this being the current Arch
glibc maintainer. :)

-Dan