-----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-----