[Libguestfs] Patchable build problems on OS X 10.10

[Daniel P. Berrange]

On Mon, Feb 09, 2015 at 10:27:21AM +0000, Richard W.M. Jones wrote:
> On Mon, Feb 09, 2015 at 10:56:54AM +0100, Pino Toscano wrote:
> > On Friday 06 February 2015 10:03:37 Richard W.M. Jones wrote:
> > > On Thu, Feb 05, 2015 at 10:53:06PM +0000, Margaret Lewicka wrote:
> > > > +/* Fixes for Mac OS X */
> > > > +#if defined __APPLE__ && defined __MACH__
> > > > +#include <sys/un.h>
> > > > +#endif
> > > > +#ifndef SOCK_CLOEXEC
> > > > +# define SOCK_CLOEXEC O_CLOEXEC
> > > > +#endif
> > > > +#ifndef SOCK_NONBLOCK
> > > > +# define SOCK_NONBLOCK O_NONBLOCK
> > > > +#endif
> > > > +/* End of fixes for Mac OS X */
> > > > +
> > > >  /* Check minimum required version of libvirt.  The libvirt backend
> > > >   * is new and not the default, so we can get away with forcing
> > > >   * people who want to try it to have a reasonably new version of
> > 
> > This IMHO is clearly wrong: the O_* constants are for open() & friends,
> > not for socket & socket4.
> 
> I checked this out before committing it, and I accepted it because on
> Linux/glibc, SOCK_CLOEXEC == O_CLOEXEC and SOCK_NONBLOCK == O_NONBLOCK
> (see the definitions in bits/socket.h and bits/socket_type.h on a
> Linux system).
> 
> Of course this is not a law of nature and there could be systems where
> this is not true.
> 
> The macros as defined only affect systems that don't define SOCK_* at
> all.
> 
> > Theoretically, we could switch the socket() usages in launch-libvirt.c
> > to socket4(), which can be replaced by gnulib if missing (we already
> > use the "accept4" gnulib module). On the other hand, it seems that
> > such gnulib emulation does not provide SOCK_NONBLOCK, so either
> > a) fix that in gnulib
> > b) use the "nonblocking" gnulib module, using set_nonblocking_flag()
> >    instead of SOCK_NONBLOCK
> 
> (b) would not be atomic.  I'm not certain if there's a case where that
> matters for O_NONBLOCK.  (Of course it definitely matters for
> O_CLOEXEC and we've have bugs caused by that in the past)

A while ago there was someone trying to port libguestfs to Windows who
was also doing crazy hacks related to sockets code. IMHO both of these
are a indicator to use gnulib for sockets portability.  The atomicity
of setting SOCK_NONBLOCK doesn't matter because the socket() call does
not do anything except allocate the resource - you need a bind/connect
call before any action takes place, so you can safely set non-blocking
mode before those in a race-free manner.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|