On Fri, 2005-05-27 at 13:45 -0400, James.Smart@xxxxxxxxxx wrote: > The transport can be a subsystem on it's own and is perhaps independent > of SCSI altogether. In this case, SCSI just happens to be a personality > of something on the transport. This is at odds with the current design > in which the transport is something under SCSI and inherently bound to > the SCSI "host". Actually, no that's no longer true. Initially I did it this way, but now the SCSI transport classes are build on top of the generic transport classes (and these are independent of SCSI). I anticipate that soon we'll get a PHY transport class that will attach both to SAS and SATA devices (and won't care which subsystem they're under). > I understand how we got to where we are, but shouldn't we consider making > some transports independent subsystems ? If the only protocol that > can be run on the transport is SCSI (ex: SPI), then the transport can be > under SCSI. However, if the transport can support multiple protocols (FC > can support SCSI, IP, (or ATA)), shouldn't it be structured more like an io > bus like pci ? > > It does mess up the device tree heirarchy. In general, you want the > device tree to continue along the transport specific elements until it finds > remote endpoints (things your going to use), at which point the protocol > specific elements can kick in. For example (using FC): > /sys/devices/<pci>/fcport5/rport-5:3/target10:0:0/10:0:0:0 - the SCSI lun > > What this leaves out is : where is the scsi host device ? It doesn't make > sense to insert it in-between the transport elements. It likely just becomes > a leaf entity. Continuing the example: > /sys/devices/<pci>/fcport5/host10 - scsi host interface > /sys/devices/<pci>/fcport5/eth3 - network interface > > Food for thought... Is this out in left field ? Well, that's why it's a class. All the devices appear under /class/<transport class name> and these devices are simply the names of the actual generic devices, so there's no reason target0:3:0 can't co-exist happily with ata3:0 or something here. The idea being (I think) that the class infrastructure actually flattens the tree. So there's always a device link that points into the true device tree, but all the class properties are available in flattened form. 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
