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) 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. It was also that time when I asked for "target" to be represented transparently so that SCSI Core can do LU discovery and register the devices found and register them with the Command Set Drivers (sd, st, etc). On all three points I saw great opposition from the maintainers. Sadly, I had implemented all those things, but the products (target and initiator) was closed source. This is where scsi_done_q and scsi commands from slab cache came from... > 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? Luben - : 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
