On Mon, 2010-10-11 at 16:18 +0200, Tejun Heo wrote: > Hello, > > On 10/06/2010 07:13 PM, Vladislav Bolkhovitin wrote: > > Tejun Heo, on 10/06/2010 06:10 PM wrote: > >> On 10/06/2010 09:24 AM, Nicholas A. Bellinger wrote: > >>>> I like to hear the opinions of SCSI maintainer and ATA folks. > >>> > >>> jejb, jgarzik, tejun and co..? Any thoughts here..? > >> > >> I frankly have no idea whatsoever. Is there something I can read to > >> educate myself on the subject? > > > > General information about a SCSI target subsystem you can find in > > http://scst.sourceforge.net. More internal details about implementation > > in http://scst.sourceforge.net/scst_pg.html. Features which are > > implemented in http://scst.sourceforge.net/comparison.html. > > > > Directly on the subject you can find some considerations in > > http://lkml.org/lkml/2010/10/1/140 (second half of the message). > > > > My opinion is that in ideal the SCSI initiator subsystem should be > > drivers/scsi/initiator and the target subsystem - drivers/scsi/target > > with shared code in drivers/scsi/. But in reality such big > > reorganization is unlikely possible, so it's better to leave SCSI > > initiator subsystem in drivers/scsi and the target subsystem - in the > > separate directory in drivers/ (drivers/scst for SCST). > > Thanks for the pointers. Yeah, it would be pretty interesting to have > ATA support there too and for ATA I don't really see why anyone would > mix the initiator and target driver implementations. They may share > protocol constants and some utility functions but that will be about > it, so it will mostly be a completely separate subsystem and I think > it probably is better to put it somewhere separate too. I think it > would be best if we can keep the two subsystems clearly separated. > They're targeting very different and most likely disjoint audiences > after all. Hi Tejun, So following hch's recent input and my series for unifying the SCSI control CDB emulation handling of virtual subsystem plugins in TCM v4.0, the actual struct se_subsystem_api abstraction itself and individual IBLOCK, FILEIO and RAMDISK subsystem plugins will now be able to function indepedent of any SCSI layer code. This will obviously still require changes to TCM proper and a functioning ATA target mode driver of course :-), but depending upon the amount of community interest in this area is something we can start looking at for .38 and .39 Best, --nab -- 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
