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 > >> 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 > >> > > > > 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..? > > 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. > > 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). 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/. > Ahhh, makes sense now.. That definitely makes things a little more difficult wrt to Directory ID based WWPN usage. > I could of course make the Directory ID an attribute of the TPG much > like I have some of the other properties, such as the number of > concurrent logins or the various timeouts. > Good idea! Pushing this into a TF_TPG_BASE_ATTR() for each sbp target is alot cleaner. > [snip] > > >> There is also an added difficulty in that a directory can't be added > >> to a single card's Config ROM in Juju, but instead is added to all > >> cards on the system. This is why I think it's important to include an > >> explicit Unit_Unique_ID, as if you have two cards possibly on the same > >> bus an initiator would see the two units on different nodes as > >> different units instead of two instances of the same unit. > >> > >> What does everyone think? > >> > > > > That sounds like a good reason use Unit_Unique_ID then.. ;) > > > > So in sbp_configfs.c code, sbp_make_tport() is currently not doing any > > type of HW port setup, which happens later in the next configfs group > > down via sbp_make_tpg() -> sbp_management_agent_register() > > > > For /sys/kernel/config/target/sbp/$SBP_WWPN registration, it would be > > cleaner to do HW target port init earlier in sbp_make_tport() and then > > use sbp_make_tpg() for an optional per port tag. If you don't want the > > tag user configurable, enforce a single /sbp/$SBP_WWPN/tpgt_1 from > > within sbp_make_tpg() and don't encode anything extra based on the tag > > in $SBP_WWN.. > > I'll get that cleaned up tomorrow. It's a relic of my earlier > misunderstanding of TPGTs. :-) > > I'll also try and send out a V1 for-review patch series to the lists as > it's probably easier to review that way. > Cool beans. Looking forward to V1. Thanks Chris! --nab -- 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
