On 24/07/12 01:37, Andy Grover wrote: > On 07/23/2012 05:04 PM, Stefan Richter wrote: >> On Jul 23 Andy Grover wrote: >>> I'm looking to add sbp support to the target userspace config tools, in >>> the form of an rtslib .spec file[1]. >>> How do I filter these properly? >> But there is a patch pending and planned to be released in v3.6-rc1 which >> adds a sysfs attribute that tells whether a node is local or remote. > Great! I'll plan on using this. Before you do, it's worth noting that the GUIDs/EUI64s used when creating the target are a different creature to the firewire device GUID in /sys/bus/firewire/devices/*/guid. You can mave many targets to a single fw_device, and each target must have a unique GUID. IIRC the standard does not mention if the target and device GUIDs should match or differ. The target GUID exists to differentiate firewire targets themselves and is an optional part of the SBP specs. Normally (on a physical firewire hard disk for example), you can identify a unit from the parent devices GUID _and_ the offset of the unit in the owning node's unit directory. In our case the offset can change regularly, units can be swapped around, all sorts - so the GUID is the only way to uniquely identify one target from another. The standard also mentions the scenario where the same target may be exposed on multiple fw buses (e.g. with 2 fw cards in one system; thus having two fw device IDs), and the GUID is required in that scenario so that initiators know they are in fact the same target and choose one or the other or multipath or whatnot. So really what I'm trying to say is I don't think selecting from the existing fw device GUIDs is the right angle to take. In my view, any EUI64 with the 'locally administered' bit set should be fair game and possibly also those with certain vendor prefixes that we might be permitted to use in this scenario (Rising Tide's? the KVM one?). HTH, 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
