On Feb 10 Nicholas A. Bellinger wrote: > On Sat, 2012-02-11 at 00:46 +0000, Chris Boot wrote: > > On 11/02/2012 00:03, Nicholas A. Bellinger wrote: > > > On Fri, 2012-02-10 at 10:39 +0000, Chris Boot wrote: > > >> On 9 Feb 2012, at 23:51, Stefan Richter wrote: > > <SNIP> > > > >> > > >> As for my target code, should I be including an explicit Directory ID > > >> as part of my target port name in the target? It seems as though > > >> that's something that should be settable seeing as the directory is > > >> not necessarily in a constant location in the config ROM at all - but Assuming that the SAM editors mistyped their "Discovery ID" and really meant "Directory ID" --- yes, having an option to configure an explicit Directory ID makes sense. Implicit Directory can be controlled by an administrator too *if* he is able to control which unit directory is added when --- including each SBP-2/-3 target unit, possibly a firewire-net unit (two if firewire-net gets expanded to IPv6), and units of any other 1394-specific program installed on the system that would add a unit (regardless if userland program or kernelspace program). So, it is hard but not impossible to control implicit directory IDs. Hence, /optional/ support of explicit directory IDs would IMO be better than either no support of them, or mandatory support i.e. forcing the user to always set an explicit directory ID. > > >> making the target ports that long and complex seems a bit harsh, > > >> especially considering all the rules that go along with it... An > > >> example target port name in this case could be: > > >> > > >> 5254000b8f01e6f6:000000 Yes it is long, but it is exactly as long as SAM specifies. :-) > > >> > > > > > > If a SCSI over IEEE 1394 target port WWN value is only coming from hw > > > and userspace is *not* formatting their own virtual WWPNs (eg: > > > iscsi_target), then under /sys/kernel/config/target/ a fabric typically > > > will enforce the use of a single $FABRIC/$TARGET_WWPN/tpgt_1/ per > > > physical HW port. > > > > Right, in this case the Unit_Unique_ID is a EUI-64 that can be chosen by > > the user. If we could limit SBP-2 units to only appear on a single > > FireWire card then it would make sense to only use the GUIDs available > > to cards on the system (and maybe not even bother with the Unit_Unique_ID). > > > > OK, in that case using hw GUIDs will probably make the mose sense for > sbp wwn group naming. As you've mentioned, there appears to be a > fabric dependent special case wrt to Unit_Unique_ID usage, but for the > majority of cases it's not going to be a hard requirement. > > Btw, are these hw GUID values already exported via sysfs..? We do have /sys/bus/firewire/devices/fw*/guid but you cannot readily use it in its current form to present a list of GUIDs to choose from. The reason is that /sys/bus/firewire/devices/ contains local nodes and remote nodes alike without a means to distinguish between them. The /dev/fw* ioctl ABI could be used for this purpose, but I suppose an extension to sysfs to distinguish local nodes from remote nodes would be more desirable. It could be added easily; the only difficulty would be to decide on name and values of such a sysfs attribute. :-) > > > > If the ':000000' suffix above is an optional user-generated fabric > > > dependent value, then one option is to map it to existing > > > se_portal_group->tpg_group level ($FABRIC/$TARGET_WWPN/tpgt_1/), and > > > encode the user-generated ->tpgt value into the directory ID suffix > > > presented on the wire. Both the upper 8 bytes and the lower 3 bytes of SAM's 11 bytes SBP-3 target identifier can potentially be used for user-defined or application-defined values, but with the restrictions which had already been mentioned. I.e. the upper 8 bytes are an EUI-64, as explained e.g. at http://standards.ieee.org/develop/regauth/tut/, and the lower 3 bytes are (presumably) a Directory_ID which must be unique within the scope of a 1394 node. > > Yes, I could see how that would work. However the problem with the > > Directory ID as I see it is it has to be unique on the entire node - > > this includes all SBP-2 units as well as anything else that could be > > present such as firewire-net or what have you. For example I couldn't > > have the following on a single target system: > > > > 5254000b8f01e6f6:000000 > > 5254000b8f01e6f7:000000 > > > > The problem with _not_ specifying it and just using the implied > > Directory ID is that the implied ID changes when the unit changes > > position in the FireWire Config ROM. This can happen if the target is > > configured before firewire-net, then the target is modified (which > > regenerates its config directory). The add-ROM-entry API uses list_add_tail. So adding a unit directory (e.g. loading firewire-net) does not change the order of unit directories. But removing a unit directory (e.g. unloading firewire-net) changes the order if some other then the very last unit is removed, of course. > > Systems that actually use the > > Directory ID as an identifier could get very confused - and udev rules > > do currently expose this in /dev/disk/by-id/. Strictly speaking, udev rules just take what firewire-sbp2 hands out through the ..../host*/target*/*:*:*:*/ieee1394_id attribute in the sysfs interface of a SCSI device, implemented by drivers/firewire/sbp2.c::sbp2_sysfs_ieee1394_id_show(). And the implementation puts there what I assumed it should, because bus architecture spec IEEE 1212-1994/-2001, the SCSI architecture spec SAM-2/-3/-4, and the transport spec SBP-2/-3 do not paint a complete and consistent picture, as noted. -- Stefan Richter -=====-===-- --=- -=-== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
