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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-12-16 at 07:43 -0700, Jan Beulich wrote:
> > > > 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.

OK, I'll make that change next time.

Ian.


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