On Fri, 2005-12-30 at 21:27 -0600, Mike Christie wrote: > > Yes, that looks fine ... it runs in user space, which was really all I > > was looking for. > > > > There is another half to this, which is that I'd like the tap to come > > via a SCSI API. This isn't strictly necessary for iSCSI but it would > > allow us to integrate a generic target approach that could work for all > > SCSI HBA's as well as just iSCSI. > > > > The code we currently have is designed to work with software iscsi > targets or software AoE and HW cards like qlogic or emulex's FC cards. > There are a lot of places we could use scsi-ml or block layer structs > like the request or scsi_cmnd. > > To support HW like qlogic or emulex's FC target mode, are you thinking > you might want us to add on to the scsi-ml's scsi_host_template or add a > scsi_target_template? If we add on to the scsi_host_template and if that > one PCI device would be in initiator and target mode at the same time > would we have one scsi_host for that resource and just add our target > related fields to the scsi_host? Is this what you mean? I'm thinking one device would do both intiator and target (although not at the same time, but probably via some sort of internal role change mechanism---Although that would be up to the driver writer; it could certainly be set up to be initiator or target only) we probably need one or two additional callbacks for sending incoming commands upwards and a control channel for specifying what we do next (since for write commands, we need command first, then userspace processing and setup then body into allocated buffer). The idea is that at the end of the project we have a well defined target infrastructure for any SCSI device (with an iSCSI reference implementation). James - : 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
