Re: [Qemu-block] [PATCH 0/2] block: Do OFD lock check at runtime

[Kevin Wolf]

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