On Mon, 2005-09-12 at 16:17 +1000, Douglas Gilbert wrote: > If we look at our (im)famous <h:c:i:l> addressing string, > the first 2 elements (i.e. "h:c") are about kernel device > addressing (i.e. which (part of a) HBA to be initiator); the > contentious "i" is about addressing the target and is > transport dependent, and the "l" is for addressing within > the target. Only the last element is true SCSI and is > defined in SAM (to be 64 bits, not 32). In iSCSI the "i" > is actually an adorned IP address. About the "i" problem, I've long agreed that we could do with an arbitrary string or other method there. There is a description of how to do it, it's just rather involved since the idea of "i" being a small number threads through a large amount of driver code making backward compatibility a bit of a nightmare. The "l" issue should be primarily solved with the scsilun_to_int and int_to_scsilun functions. OK, horribly named, but they now mean that the internal mid-layer representation (a 32 bit int currently) is abstracted from the structure the drivers use on the wire so we should be free to increase it if necessary. Note: you do actually need either an array with more than two levels of nesting actually to need the increase and no-one actually seems to have one of these yet. > So the kernel "discovers" at the "h:c" level at powerup > (and at runtime with hotplug events); leaving the SCSI > subsystem to do discovery at the "i" and the "l" level. > > At this point I would like to make an observation: there > is no absolute requirement for the SCSI subsystem to do > discovery at either the "i" or the "l" levels. Using SAS Right, but we've already moved away from that if you use the correct APIs. The fc transports (those that attach to the transport class, anyway) no longer use the mid-layer provided sequential scan. They simply add targets that the fibre discovers from the log in process. Essentially this means that the class/driver co-operate on discover and only use the mid-layer for LUN detection once they report the existence of a target. > as an example, only the SAS (target port) address and > a logical unit number (identifier) or name are needed. > So an embedded system which includes a SAS initiator (HBA) > could connect to an arbitrary device quickly and with > minimal impact on a large SAS fabric (i.e. no SAS target > discovery phase). As an extreme example, target discovery > in iSCSI cannot involve the whole internet (and even though > its topology would be interesting, representing it in sysfs > is absurd). > My major objection to Luben's SAS sysfs representation is > that "things" have to be discovered before the user space > can talk to them. Why?? An app in the user space might > _know_ that the "thing" (e.g. SAS expander or a "well > known" logical unit) is out there. Again the obvious comparison > is with IP addresses and the way the networking subsystem > functions. I would like to make HBA initiators (or their ports) > visible as interfaces (like eth0 and friends) through which > commands/frames/primitives can be sent and events received. This one, I actually agree with. Most users have small domains which will be easily amenable to total enumeration. The other issue is that if we go with a socket like approach where the user has to connect to the devices, then we lose hotplug ... a true network doesn't know or care when another PC is plugged into it. For things like iscsi, we do have the compromise that discovery doesn't begin until the endpoint is known. If we go like net and have the whole world as our potential but non- discovered domain, we have to begin addressing security issues that arise because of the parts of the domain that we don't control ... I'd much rather leave these sort of issues to the net people and begin with the a priori assumption that a scsi domain, although it might be bridged across the hostile network, represents a fundamentally secure and discoverable system. 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
