Re: [Qemu-devel] [RFC] O_EXCL or not open block device

[Paolo Bonzini <pbonzini@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 13/09/2013 00:48, NeilBrown ha scritto:
>> I'm not sure why O_EXCL would be correct on generic block
>> devices when it's wrong on CD-ROMs. I think it's in fact more
>> likely that other devices are shared, as backing files.
> 
> O_EXCL make sense if you or someone else might change the contents.
> If the device is read-only, or is uniformly treated as read-only,
> then O_EXCL is unnecessary and could definitely get in the way. I
> would be nice if we had O_SHARED and O_EXCL, but unfortunately we
> don't.... I wonder if O_EXCL|O_RDONLY could be treated as a shared
> lock....  Maybe one day.

Even that won't really work well for CD-ROM passthrough, because
ejecting a CD certainly affects the other openers but is available
with O_RDONLY.

A policy on sharing block devices that are used "just for the data"
does not belong in QEMU, it belongs in management. As such, I don't
think that QEMU should blindly use O_EXCL on all block devices.

My patch series used O_EXCL for CD-ROMs only to disable kernel event
polling; in other words, basically as a workaround. There are other
reasons why not sharing a host CD unit makes sense; for example, ATAPI
event polling is edge-triggered and simply doesn't work with multiple
VMs attached. But if the sharing policy could be left exclusively to
management above QEMU, it would be better to do so.

I think if someone wants to attach a real CD-ROM disc to a VM just for
the data (e.g. ejecting the disc will not open the real tray) they
should use something like "file:/dev/sr0". Then QEMU would not use
O_EXCL even with my patch series.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSMrvAAAoJEBvWZb6bTYbyZZMQAJIxy9jeo7/mKKrchvMs8uRY
3xN4IYtEJX15tAymsBCybW4t1Vr6P+N6I6zlFhdNCpY+o8Sckm5RV1a+1dJp5cz4
6JhAnEeddoZeEzBZorcpRCLkRZwiX2lECNsD2+cakXhprn5I+Mphd9xLBHb7FMZA
eRKn3Fe4+wAFXXqanzy8SxjK7S6IN+0su6mfKqQF94HxLVM9f2EBlfFm20rUJ4jS
PEhSJ2kPVMvanfDGUYzIfwP/eMBKJ8+95jBpcw1YBjn1U1V1c5wLguSyHGUacs8G
sOc0X20vuK0bF9oMFYvkMaQHEnwKvNWg640pkqzWe4F2Oe73pim7kVAJzQGD4+s5
SnglMBsH+0wjA85KPwJOD3+Tv58mTbTLiQDQVC/hX9p1JCZPeptXYEiYhcNwWHWF
RGM87PB9QuopE2TQJnRCPUDz9oZDX25cscZwKbsWriHAwTub4+PGm2LTARwC5ByM
0v+QCEzE7FmqEuE4K680iwKKVVWP/x1Mqn8/XW27+liOpL2FgBsPZDn27YcKQGlc
UOHLs1X0g/4CSHNq4LacthgPNihNnLQ9TwZiO+P9HimpnfjWW3KfkxjvqaaWANot
Tg13mS1GpxagXY675keddSLQ7GdBHkDh64R4hUzSmjrg/j9UQKChXz9ycArZ4b+t
zEZy1H/cLiwwzEUm8hj8
=6pli
-----END PGP SIGNATURE-----