[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.