Re: [Libguestfs] [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe()

On Tue, Feb 21, 2023 at 11:59:30PM +0100, Laszlo Ersek wrote: > On 2/21/23 19:04, Daniel P. Berrangé wrote: > >> AFAIK, libnbd/nbdkit haven't made a statement about what platforms >> they aim to target. In my response I'm more or less assuming though >> that you would only care about similar modern platforms to QEMU/libvirt, >> and thus POSIX conformance would not be needed in all areas. Maybe >> libnbd/nbdkit want to be more explicit about what they target as >> platforms to make the portability requirements clear to contributors ? > > libnbd's README.md requires > > * Linux, FreeBSD or OpenBSD. > Other OSes may also work but we have only tested these three. > * GCC or Clang > * GNU make > * bash > * [...] > > nbdkit's requires > > * Linux, macOS, Windows, FreeBSD, OpenBSD or Haiku > * GCC or Clang > * bash > * GNU make > * [...] > > To me, anything beyond Linux on those OS lists is entirely untestable > *locally*, hence my reliance on POSIX. CI is a horrible way (compared to > a published technical standard) to figure out whether each individual > interface works as needed everywhere, even just across this small set of > OSes. Having to look at multiple OS manual pages is just slightly less > horrible (and I consider those less trustworthy than POSIX; see again > the conflict between the linux man pages and the glibc documentation > from GNU). The POSIX people have done *huge work* to save us that effort. FWIW, my (bitter) experience from both libvirt and QEMU is that unless you have CI validating it, you don't have portability to a platform, no matter how much effort the developers put in complying with standards and/or manual pages. The reality of bizarre/broken platform impls always gets in the way of good intentions. FWIW, in terms of testing locally, all those platforms are trivial, with the exception of macOS. For Windows, mingw toolchain will get you through all compilation portability problems which is 90% of the work. While you can use WINE for some functional testing, a real Windows VM is better. For the *BSD / Haiku, a VM can be spun up with KVM quite easily. macOS is the real pain point because of its restrictive EULA meaning you basically have to buy it. It makes it very much a second class citizen for developers, unless they happen to have personal apple hardware.