On 2/22/23 10:25, Daniel P. Berrangé wrote: > 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.
Thank you. Laszlo _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
