Re: [Xen-devel] [PATCH XEN v7 27/29] tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.12.15 at 15:04, <ian.campbell@xxxxxxxxxx> wrote:
> On Wed, 2015-12-16 at 06:16 -0700, Jan Beulich wrote:
>> > > > On 16.12.15 at 13:31, <ian.campbell@xxxxxxxxxx> wrote:
>> > --- a/tools/libs/call/linux.c
>> > +++ b/tools/libs/call/linux.c
>> > @@ -26,15 +26,23 @@
>> >  
>> >  #include "private.h"
>> >  
>> > +#ifndef O_CLOEXEC
>> > +#define O_CLOEXEC      02000000
>> > +#endif
>> 
>> Is that a good idea? Wouldn't you better define to zero if building on
>> an old glibc, assuming you'd then also run on an old kernel?
> 
> Good point, I was only considering the old userspace but with newer kernel
> case. Since O_CLOEXEC was implemented in 2.6.23 I was expecting we could
> just rely on its presence, but you mentioned that you sometimes used newers
> kernels with older glibcs.

I do (and specifically don't run old kernels under newer glibc), but
along with the old kernel consideration it is also unclear to me
whether we can rely on old glibc to not barf on bits they don't
know, irrespective of whether the kernel knows. I.e. I still think
that - unless you want to probe for support at runtime, or also
evaluate the kernel version of the kernel headers installed - using
zero here would be the most compatible approach.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel