On Wed, 2015-12-16 at 06:16 -0700, Jan Beulich wrote:
> > > > On 16.12.15 at 13:31, <ian.campb...@citrix.com> wrote:
> > --- a/tools/libs/call/freebsd.c
> > +++ b/tools/libs/call/freebsd.c
> > @@ -35,8 +35,14 @@
> >
> > int osdep_xencall_open(xencall_handle *xcall)
> > {
> > - int flags, saved_errno;
> > - int fd = open(PRIVCMD_DEV, O_RDWR);
> > + int saved_errno;
> > + int fd = open(PRIVCMD_DEV, O_RDWR|O_CLOEXEC);
>
> No compatibility define needed for FreeBSD?
No, the kernel and libc are more tightly integrated there.
> > --- 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.
In the end I don't think I mind either way.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
