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>
I just posted a commit to my github repo which does the following:
1. Maps SAM target ports to IEEE-1212 units.
2. Insists that a target port within the target framework is named using
an EUI-64/GUID and exposes this in the IEEE-1212 unit directory's
Unit_Unique_ID property.
So now we need to support unit unique ID in our initiator too.
I can volunteer to do that if you like. I could prepare a patchset for
firewire-sbp2 including taking notice of Unit_Unique_ID, ignoring the
local node and fixing a couple of minor issues in
sbp2_status_to_sense_data() where we mishandle the VALID, MARK, EOM
and ILI bits.
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).
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/.
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.
[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.
Cheers,
Chris
--
Chris Boot
bootc@xxxxxxxxx
--
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
