On Wed, 2012-07-11 at 14:37 -0400, Christoph Hellwig wrote: > On Wed, Jul 11, 2012 at 10:44:11AM -0700, Andy Grover wrote: > > > > target_core_iblock.c:686 iblock_get_device_type returns TYPE_DISK > > > > also target_core_iblock.c iblock_parse_cdb calls sbc_parse_cdb, which > > doesn't support MMC cmds. > > So? That's what is exported to the initiator. All iblock needs as > backend is a bloock device, and that might as well be a MMC device. > You just won't be able to use additional functionality supported by > MMC devices. > > > also the fact we started with, that rtslib is working hard to make sure > > only TYPE_DISK block devices are allowed for iblock. > > Wouldn't be the first time that it's overzealous for no reason at all. > IBLOCK has historically had issues trying to register a non TYPE_DISK struct block_device as a target backend, which is what the rtslib code in question is trying it's best here to avoid. Now it's certainly OK to have a kernel patch that can change the device TYPE_* emulation reported to the initiator for special cases. For example, Dr. Hannes has a patch for FILEIO that allows a LUN to export .iso files over target fabric LUNs reporting TYPE_ROM. But aside from that type of patch, AFAICT the struct block_device backend for IBLOCK still needs to be raw block or a scsi_device w/ TYPE_DISK. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
