block/file-posix.c | 19 ++++++-------- include/qemu/osdep.h | 1 + util/osdep.c | 72 +++++++++++++++++++++++++++++++++++++++++++++------- 3 files changed, 72 insertions(+), 20 deletions(-)
This fixes the image opening failure reported by Andrew Baumann: > I'm running a recent Linux build of qemu on Windows Subsystem for Linux (WSL) > which doesn't appear to implement file locking: > > $ 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 It appears to be that the binary is built for Linux targets, but the WSL runtime doesn't recognize the ops (-EINVAL). Convert to runtime check to cope with that. Fam Zheng (2): osdep: Add runtime OFD lock detection file-posix: Do runtime check for ofd lock API block/file-posix.c | 19 ++++++-------- include/qemu/osdep.h | 1 + util/osdep.c | 72 +++++++++++++++++++++++++++++++++++++++++++++------- 3 files changed, 72 insertions(+), 20 deletions(-) -- 2.13.3
Am 21.07.2017 um 12:20 hat Fam Zheng geschrieben: > This fixes the image opening failure reported by Andrew Baumann: > > > I'm running a recent Linux build of qemu on Windows Subsystem for Linux (WSL) > > which doesn't appear to implement file locking: > > > > $ 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 > > It appears to be that the binary is built for Linux targets, but the WSL > runtime doesn't recognize the ops (-EINVAL). > > Convert to runtime check to cope with that. Fair enough in this specific case because we still support older Linux kernels and we want to fail gracefully if the binary was built against a newer kernel. However, I think the real problem here is with the WSL ecosystem if qemu is routinely built against a real Linux while WSL doesn't provide the same functionality. WSL should provide kernel headers that match what it can provide (i.e. either remove the unimplemnted constants or implement them). So for the future, I'm not sure that we should add workarounds for WSL shortcomings when no real Linux is affected. This is even more true when the reporter is a Microsoft employee. Kevin
On 07/21/2017 06:56 AM, Kevin Wolf wrote: >> >> Convert to runtime check to cope with that. > > Fair enough in this specific case because we still support older Linux > kernels and we want to fail gracefully if the binary was built against > a newer kernel. Or, more likely: if we are built against a newer glibc (that has the constants) but an older kernel (that lacks support for the constants). > > However, I think the real problem here is with the WSL ecosystem if qemu > is routinely built against a real Linux while WSL doesn't provide the > same functionality. WSL should provide kernel headers that match what > it can provide (i.e. either remove the unimplemnted constants or > implement them). In other words, you're arguing that binaries built for WSL should be cross-compiled rather than native compiled (similar to how mingw binaries are built in a Cygwin environment), such that the cross-compiler picks up the correct altered headers for WSL limitations. I agree - but I have no influence on how likely that is to come about. > > So for the future, I'm not sure that we should add workarounds for WSL > shortcomings when no real Linux is affected. > > This is even more true when the reporter is a Microsoft employee. > > Kevin > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Fri, Jul 21, 2017 at 07:34:11AM -0500, Eric Blake wrote: > On 07/21/2017 06:56 AM, Kevin Wolf wrote: > >> > >> Convert to runtime check to cope with that. > > > > Fair enough in this specific case because we still support older Linux > > kernels and we want to fail gracefully if the binary was built against > > a newer kernel. > > Or, more likely: if we are built against a newer glibc (that has the > constants) but an older kernel (that lacks support for the constants). > > > > > However, I think the real problem here is with the WSL ecosystem if qemu > > is routinely built against a real Linux while WSL doesn't provide the > > same functionality. WSL should provide kernel headers that match what > > it can provide (i.e. either remove the unimplemnted constants or > > implement them). > > In other words, you're arguing that binaries built for WSL should be > cross-compiled rather than native compiled (similar to how mingw > binaries are built in a Cygwin environment), such that the > cross-compiler picks up the correct altered headers for WSL limitations. > I agree - but I have no influence on how likely that is to come about. IIUC, the core selling point of WSL was that you can take an existing Ubuntu (or now various other Linux) distro and just run it "as is", without recompiling its specially. So this really is best thought of as the build with new glibc+kernel, but run on old kernel scenario. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.