>>>>> "Paolo" == Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: Paolo> First of all, I'll note that SG_IO and block-device-specific Paolo> ioctls both have their place. My usecase for SG_IO is Paolo> virtualization, where I need to pass information from the LUN to Paolo> the virtual machine with as much fidelity as possible if I choose Paolo> to virtualize at the SCSI level. Now there's your problem! Several people told you way back that the SCSI virt approach was a really poor choice. The SG_IO permissions problem is a classic "Doctor, it hurts when I do this". The kernel's fundamental task is to provide abstraction between applications and intricacies of hardware. The right way to solve the problem would have been to provide a better device abstraction built on top of the block/SCSI infrastructure we already have in place. If you need more fidelity, add fidelity to the block layer instead of punching a giant hole through it. I seem to recall that reservations were part of your motivation for going the SCSI route in the first place. A better approach would have been to create a generic reservations mechanism that could be exposed to the guest. And then let the baremetal kernel worry about the appropriate way to communicate with the physical hardware. Just like we've done with reads and writes, discard, write same, etc. The fact that burning CDs requires SG_IO in the first place is just a symptom that we got that interface totally wrong. cat iso.img > /dev/sr0 would have been much more in line with how Unix works... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
