On Thu, Aug 18, 2005 at 04:05:29PM -0400, Luben Tuikov wrote: > On 08/18/05 13:56, Christoph Hellwig wrote: > > I was trying to avoid the need for an rport object, but I'm not yet sure > > it's feasible. We certainly won't put in target-persistency support > > similar to FC, that was just a hack to get the existing drivers migrated > > without lots of complaints, it's not going in for new transports like > > SAS or iSCSI. > > Hmm, I remember working on iSCSI exactly 5 years ago. > Is this considered new? (er, I mean in light of SCSI Core) We've just added the first iSCSI LLDD (the open-iscsi software initiator) to the scsi git trees, so yes, this is considered new. > I also remember it was that time when I asked about 8 byte LUNs > to be supported transparently by SCSI Core. > > It was also that time when I asked for "target" to be supported > without "channel" and "id" as this had to be invented by > the iSCSI LLDD as it needs to be invented by FC and USB. Or just ignored. > > What we might need an rport for is to support SMP. I'm > > not yet sure how to do SMP passthrough, but we will need some object > > to represent SMP ports. > > Why? How is this going to be used? What is the architecture model? We need some way to implement SMP passthrough. One of the options is to have a passthrough node that frames can be written to - for that we obviously need an object for non-scsi target sas remote ports. - : 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
