Returns EFAULT for no discernable reason.

Now ‘--disable-plugins’ can be removed from the previous commit to
enable some plugins and run them under wine:

  sudo dnf install mingw64-gcc mingw64-dlfcn \
                   mingw64-gnutls mingw64-xz mingw64-zlib
  mingw64-configure
  make
  wine ./server/nbdkit.exe -fv \
       ./plugins/memory/.libs/nbdkit-memory-plugin.dll size=1M

This allows nbdkit to be cross-compiled for Windows (from Linux).  On
Fedora[1] you would use the commands below:

  sudo dnf install mingw64-gcc mingw64-dlfcn \
                   mingw64-gnutls mingw64-xz mingw64-zlib
  mingw64-configure --disable-plugins
  make

This results in a Windows binary which can be run on Windows or on
Linux under Wine.

It also probably allows nbdkit to be compiled on Windows natively
using the mingw-w64 port of GCC, but I did not test that.

There are several limitations compared to running nbdkit on a real
server, see ‘TODO’ for the complete list.

[1] Note that mingw64-configure is a Fedora-specific script which runs
./configure with extra parameters to make cross-compilation for
Windows work.  You can add other configure parameters to the command
or if you're not using Fedora then use ‘./configure --host=...’
instead.

This is really a replacement for a missing platform function, so use
the same LIBOBJS mechanism to replace it.

Especially on Windows, some common functions are missing.  Use the
autoconf LIBOBJS mechanism to replace these functions.

This includes replacement functions for:

  Function names     Implementation   Origin

  getdelim, getline  general purpose  NetBSD under a compatible license

  openlog, syslog,   Win32            written by me
  vsyslog

  realpath           Win32            written by me

  strndup            general purpose  written by me

This should do nothing on existing supported platforms.  It is only
intended in preparation for porting nbdkit to Windows.

In commit 3775916 (and before that in
discussions with Eric) we decided that we should try to allow plugins
to be compiled with C compilers other than GCC or Clang (or with very
old / peculiar / incompatible versions of those compilers).

However until we test this we cannot guarantee that changes to the
code will not break this in future, hence this test.

Note that GCC or Clang is still required to compile nbdkit itself.

When an ANSI/C90 plugin compiled with ‘-pedantic’ uses
NBDKIT_HANDLE_NOT_NEEDED it gets the error:

  ISO C forbids conversion of function pointer to object pointer type

This is because the existing macro worked by returning a function
pointer but in C90 function pointers cannot be cast to data pointers
since on some ancient architectures code and data pointers were
incompatible.

We only need a convenient global data pointer here, and the address of
‘errno’ should be fine.

The server can link to libselinux to support SELinux socket labelling.
However because we added the library to $LIBS it got linked into
everything, eg:

$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-memory-plugin.so |
    grep NEEDED
  NEEDED            Shared library: [libselinux.so.1]
  NEEDED            Shared library: [libc.so.6]

Libselinux has a pkg-config file so we can use that to detect
the library and adjust server/Makefile.am so it is only linked
into the server.

This dependency is still optional.

Fixes FreeBSD and OpenBSD compilation which was broken by the code
refactoring in commit 6193863.

Winsock only lets you use send/recv, and it shouldn't make any
difference on Linux either.

This is a simple refactoring of the function, allowing us to
reimplement the inner loop for Windows in a future commit.  Note that
I made explicit that fds[nr_socks] is used for the quit_fd entry,
previously this was implicit which was somewhat confusing.

This split is simple code motion.  However it does allow two things:
we can document more clearly the interfaces between the main code and
these functions, and it makes it a bit easier to provide alternative
implementations for Windows.

No functional change, simply refactoring.

This fixes a debugging message which showed the incorrect size
variable.

Also tidy up an existing declaration so it matches similar decls
elsewhere in the header file.

In commit 6c4092a we introduced the
concept of the open callback returning NBDKIT_HANDLE_NOT_NEEDED for
plugins which do not need a handle.  The C++ test uses this archetype
too, but in a slightly different form so that commit did not modify
this test plugin before.

Fixes commit 627727e which omitted to
updated the manual.

…allel.

Instead of implicitly locking around every request, use an explicit
and (slightly) more fine-grained lock, and change the thread model to
parallel.  The same change is made to the memory plugin and the data
plugin.

This improves performance slightly.  Using fio with 8 threads and
multi-conn enabled with -C 8:

Before:
   read: IOPS=103k, BW=401MiB/s (420MB/s)(46.0GiB/120002msec)
  write: IOPS=103k, BW=401MiB/s (420MB/s)(46.0GiB/120002msec)

After:
   read: IOPS=112k, BW=437MiB/s (458MB/s)(51.2GiB/120001msec)
  write: IOPS=112k, BW=437MiB/s (458MB/s)(51.2GiB/120001msec)

For comparison:

The memory plugin implemented using a simple malloc instead of a
sparse array:
   read: IOPS=133k, BW=518MiB/s (544MB/s)(60.7GiB/120002msec)
  write: IOPS=133k, BW=518MiB/s (543MB/s)(60.7GiB/120002msec)

Directly running fio against /dev/shm:
   read: IOPS=1018k, BW=3978MiB/s (4171MB/s)(466GiB/120001msec)
  write: IOPS=1018k, BW=3979MiB/s (4172MB/s)(466GiB/120001msec)

These plugins use NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS because
of their use of the global sparse array.  However since they are both
RAM disks, and thus (a) flush is a no-op, and (b) the locked part of
each request is short, it is both safe and there is some performance
benefit to using NBD_FLAG_CAN_MULTI_CONN.

Without multi-conn:

   read: IOPS=52.8k, BW=206MiB/s (216MB/s)(24.2GiB/120002msec)
  write: IOPS=52.8k, BW=206MiB/s (216MB/s)(24.2GiB/120002msec)

With multi-conn (-C 8):

   read: IOPS=103k, BW=401MiB/s (420MB/s)(46.0GiB/120002msec)
  write: IOPS=103k, BW=401MiB/s (420MB/s)(46.0GiB/120002msec)

This plugin has a parallel thread model and handles flush correctly
across connections, so return NBD_FLAG_CAN_MULTI_CONN.

This allows multiple connections from a single client, and should be
safe assuming flush/FUA has been implemented correctly in the previous
commit.

Using the file plugin, but locating the file on /dev/shm, I obtained
the following results.

No multi-conn:

   read: IOPS=52.0k, BW=203MiB/s (213MB/s)(23.8GiB/120002msec)
  write: IOPS=52.0k, BW=203MiB/s (213MB/s)(23.8GiB/120002msec)

Multi-conn (-C 8):

   read: IOPS=122k, BW=477MiB/s (500MB/s)(55.9GiB/120002msec)
  write: IOPS=122k, BW=477MiB/s (500MB/s)(55.9GiB/120002msec)

Upgrade this plugin to version 2 of the API.  The main change is
implementing FUA support.

It is safe to return NBD_FLAG_CAN_MULTI_CONN from almost all readonly
plugins.  However only do it where the plugin thread model is
NBDKIT_THREAD_MODEL_PARALLEL and the plugin could plausibly be used in
a high performance situation.

I examined each filter to see which ones implement a cache and do not
properly consider consistency across clients for flush requests.  For
these filters we should force .can_multi_conn to return false.

I believe only one filter (blocksize) needs to be updated and all the
other ones are safe.