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

[Allan McRae]

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