[Libguestfs] nbdkit / mingw support

[Frank Gu]

Answering a few questions:

* Unclear why it's necessary to rename nbdkit-common.h -> nbdkit-compat.h
- It's not a rename, but a new file. nbdkit-compat.h is included for PE DLL
  compatibility, and is included in nbdkit-common.h

* Functions are indirected through struct nbdkit_functions
  _nbdkit_functions which I guess is necessary because of PE linking
  (we've had similar problems with PE linking restrictions in other
  programs).  However I wasn't very clear how this actually works, and
  we cannot break existing Linux binaries, so this needs more thought
  and must be conditional on Windows only.
- There are macro checks for an windows environment. If it's windows,
  then indirection is used. Otherwise, the original extern definitions are
used.
  This shouldn't cause an ABI change on Linux.

* Is there no way to get the socket peer on Windows?
- It's not a lack of ways that prevents me from implementing this.
  The nbdkit port is to MSYS2 (which is a superset of mingw-64), and this is
  needed because nbdkit uses an extensive set of POSIX features that
  are not present in mingw-64, e.g. fork). This port requires MSYS2 to run.
  However, the user might choose to implement the plugins / filters using
  mingw-64, or just MSVC runtime, and I don't want to bind users to MSYS2.
  Now this causes a potential ABI incompatibility: MSYS2 socket definitions
  are provided by sys/socket.h, but mingw-64 / MSVC socket definitions are
  usually provided by winsock.h or winsock2.h. To prevent possible issues,
  I removed nbdkit_peer_name. This function is not defined in the include
  headers if Windows is detected, so it will cause a compile time error if
  someone attempts to use it.


On Sat, Mar 21, 2020 at 1:20 PM Richard W.M. Jones <rjones at redhat.com>
wrote:

> On Sat, Mar 21, 2020 at 12:06:15PM +0000, Richard W.M. Jones wrote:
> >
> https://github.com/gyf304/nbdkit/commit/20d888fbb8ccf33f0975a070df0d8e3d929b71f8
> >
> > * Is there no way to get the socket peer on Windows?
>
> And assuming there's no way to get the socket peer, then the function
> shouldn't be NULL (which will cause a segfault), but instead you
> should make the function return an error.  eg:
>
>  int
>  nbdkit_peer_name (struct sockaddr *addr, socklen_t *addrlen)
>  {
> +#ifndef WINDOWS
>    [... existing code unchanged ...]
> +#else
> +  nbdkit_error ("returning peer name is not supported on Windows");
> +  return -1;
> +#endif
>  }
>
> If the problem is that msys doesn't have struct sockaddr or socklen_t,
> then I guess conditionally #defining them?  Eric knows about this
> better than I do.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200321/9f008f24/attachment.htm>