On Fri, 13 Dec 2024 at 11:04, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 12/13/24 16:51, Richard W.M. Jones wrote: > > The libnfs asynch API has changed type signature in this new version. > > This change breaks qemu and it wasn't immediately obvious to me how to > > fix it. In particular the new API requires a buffer to be passed, but > > it's unclear what that would be. > > > > Old signature: > > > > EXTERN int nfs_pread_async(struct nfs_context *nfs, struct nfsfh *nfsfh, > > uint64_t offset, uint64_t count, nfs_cb cb, > > void *private_data); > > > > New signature: > > > > EXTERN int nfs_pread_async(struct nfs_context *nfs, struct nfsfh *nfsfh, > > void *buf, size_t count, uint64_t offset, > > nfs_cb cb, void *private_data); > > > > (Similar changes are made to pwrite_async) > > Looks like the buffer used to be allocated by libnfs and passed to > nfs_co_generic_cb: > > static void > nfs_co_generic_cb(int ret, struct nfs_context *nfs, void *data, > void *private_data) > > Now it has to be allocated by the application. > > (upstream commit https://github.com/sahlberg/libnfs/commit/5e8f7ce273308) > > > I guess this needs upstream qemu attention. > > And should it also block the libnfs update in Fedora, since QEMU is a > critical package?
Hi Ronnie, This libnfs nfs_pread_async() API change breaks the QEMU build. This email thread discusses holding off on updating libnfs 5 -> 6 in Fedora, but the update has already happened in Homebrew so the QEMU macOS CI is now failing: https://gitlab.com/qemu-project/qemu/-/jobs/8646124898 Do you plan to release a new libnfs version that restores API compatibility or has the ship sailed and applications need to detect this at compile time? Thanks, Stefan
