summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorFam Zheng <famz@redhat.com>2017-08-11 19:44:47 +0800
committerKevin Wolf <kwolf@redhat.com>2017-08-11 14:12:44 +0200
commit2b218f5dbcca5fe728b1852d161d7a21fd02b2f5 (patch)
tree515a8cbe2767282a5bf6f33eac20cde3cc0264a4 /README
parentca749954b09b89e22cd69c4949fb7e689b057963 (diff)
downloadqemu-2b218f5dbcca5fe728b1852d161d7a21fd02b2f5.tar.gz
file-posix: Do runtime check for ofd lock API
It is reported that on Windows Subsystem for Linux, ofd operations fail with -EINVAL. In other words, QEMU binary built with system headers that exports F_OFD_SETLK doesn't necessarily run in an environment that actually supports it: $ qemu-system-aarch64 ... -drive file=test.vhdx,if=none,id=hd0 \ -device virtio-blk-pci,drive=hd0 qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to unlock byte 100 qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to unlock byte 100 qemu-system-aarch64: -drive file=test.vhdx,if=none,id=hd0: Failed to lock byte 100 As a matter of fact this is not WSL specific. It can happen when running a QEMU compiled against a newer glibc on an older kernel, such as in a containerized environment. Let's do a runtime check to cope with that. Reported-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions