[git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly

[Mike Frysinger]

On Tue, Jul 12, 2011 at 16:55, Rich Felker wrote:
> On Tue, Jul 12, 2011 at 03:05:56PM -0400, Mike Frysinger wrote:
>> On Tue, Jul 12, 2011 at 14:54, Rich Felker wrote:
>> > On Tue, Jul 12, 2011 at 11:47:51AM -0400, Mike Frysinger wrote:
>> >> On Tue, Jul 12, 2011 at 10:37, Khem Raj wrote:
>> >> > On 07/11/2011 08:39 PM, Mike Frysinger wrote:
>> >> >> On Friday, July 01, 2011 17:50:15 Khem Raj wrote:
>> >> >>> --- a/include/sys/signalfd.h
>> >> >>> +++ b/include/sys/signalfd.h
>> >> >>> @@ -64,6 +64,15 @@ enum
>> >> >>>  # define SFD_NONBLOCK SFD_NONBLOCK
>> >> >>>    };
>> >> >>>
>> >> >>> +#elif defined __mips__
>> >> >>> +enum
>> >> >>> +  {
>> >> >>> +    SFD_CLOEXEC = 02000000,
>> >> >>> +# define SFD_CLOEXEC SFD_CLOEXEC
>> >> >>> +    SFD_NONBLOCK = 0200
>> >> >>> +# define SFD_NONBLOCK SFD_NONBLOCK
>> >> >>> +  };
>> >> >>
>> >> >> seems like this would be better as a bits/signalfd.h rather than inlining
>> >> >> arch ifdef checks all over the place
>> >> >
>> >> > there is tendency to consolidate headers thats why its like this. Initially
>> >> > I wondered too
>> >>
>> >> yes, so the common pieces arent duplicated.  i didnt mean copy the
>> >> entire file to bits/signalfd.h, just break out the arch-specific
>> >> pieces.
>> >>
>> >> also, signalfd() last i checked is linux-specific.  so it shouldnt be
>> >> in include/ ... it needs to be in libc/sysdeps/linux/...
>> >
>> > Are the values always the same as the O_ constants from fcntl.h? If
>> > so, it's stupid that they even exist, but the cleanest solution would
>> > be to just have signalfd.h include fcntl.h and then use
>> >
>> > #define SFD_NONBLOCK O_NONBLOCK
>> > #define SFD_CLOEXEC O_CLOEXEC
>>
>> i vaguely recall the same situation coming up on the glibc lists, and
>> the same proposal thrown up, but it was swatted down for two reasons:
>>  - it pollutes the name space (including signalfd.h should not
>> implicitly include fcntl.h)
>
> I would consider sanctity of the namespace pretty irrelevant when
> you're using a highly Linux-specific feature. Certainly there's no
> standard document that says signalfd.h can't include fcntl.h because
> it's not covered by any standard to begin with.

while true, the purist in me still finds it distasteful ;).  and what
is Linux-specific today could be in POSIX tomorrow!  just look at the
all the fun new funcs in 2008 vs 2004 specs to see this isnt
unthinkable.

>>  - most, but not all, arches are the same (but maybe i remember this wrong)
>
> Why do the kernel developers keep doing idiotic things like this?
> *sigh*

well, once you're stuck with an overlapping pile, there's really
nothing you can do to sort them out.  you might be able to blame the
original source, but past that, they're pretty much pucked.
-mike