Martin K. Petersen, on 05/22/2013 09:32 AM wrote: > 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.
Well, any abstraction is good only if it isn't artificial, so solving more problems than creating. Reality is that de facto in the industry _SCSI_ is the abstraction for block/direct access to data. Look around. How many of systems around you after all layers end up to SCSI commands in their storage devices? Linux block layer is purely artificial creature slowly reinventing wheel creating more problems, than solving. It enforces approach, where often "impossible" means "impossible in this interface". For instance, how about copy offload? How about reservations? How about atomic writes? Look at history of barriers and compare then with what can be done in SCSI. It's still worse, because doesn't allow usage of all devices capabilities. Why was it needed to create special blk integrity interface with the only end user - SCSI? Artificial task created - then well solved. Etc, etc. The block layer keeps repeating SCSI. So, maybe, after all, it's better to acknowledge that direct usage of SCSI without any intermediate layers and translations is more productive? And for those minors not using SCSI internally, translate from SCSI to their internal commands? Creating and filling CDB fields for most cases isn't anyhow harder, than creating and feeling bio fields. So, I appreciate work Paolo is doing in this direction. At least, the right thing will be on the virtualization level. I do understand that with all existing baggage replacing block layer by SCSI isn't practical and not proposing it, but let's at least acknowledge limitations of the academic block abstraction. Let's don't make those limitations global walls. Many things better to do using direct SCSI, hence let's do the better way. Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
