On Feb 02 Andy Grover wrote: > On 02/02/2012 02:26 AM, Chris Boot wrote: > > PS: if you try to actually use it, you have to blacklist the > > firewire-sbp2 module or bad things will happen as it tries to connect to > > the target on the local node. Our 1394 driver stack does not differentiate much between local node and remote nodes. Representations of nodes by firewire-core (instances of struct fw_device, visible in sysfs as /sys/bus/firewire/fw[0-9]+) are indistinguishable in this regard; a distinction is only made deeper down at the bare-metal I/O level. Obviously, since the typical use of a Linux SBP-2 target would be to let one other node be initiator (as opposed to the local node being target and initiator at the same time, or to the local node and other nodes being concurrent initiators if the target supports multiple initiators), the default but possibly reconfigurable behavior of firewire-sbp2 should become to ignore targets on the local node. This is easy to implement. Actually I don't think firewire-sbp2 is currently able to work with a local target because the above mentioned distinctions deep down at I/O level are not fully fleshed out for such an occasion. Maybe, to keep things simple, leave out support for the case of target and initiator on the same node entirely for the time being. > Does just registering the management agent cause firewire-sbp2 start > poking us? What is it keying off? It starts when the target driver adds the SBP-2 unit directory to the local Configuration ROM. Then firewire-core discovers that unit and creates a struct fw_unit instance for it (child of an fw_device instance), just the same as if it were discovered on a remote node. This is because the respective facility in firewire-core lives at one of those higher levels where we don't distinguish between remote nodes and local nodes. Then firewire-core via driver core hands the struct fw_unit instance over to firewire-sbp2 to bind to. I haven't looked at Chris' code yet; but the part of the SBP-2 target driver which adds the Configuration ROM entry should look very much like http://lxr.linux.no/#linux+v3.2/drivers/firewire/net.c#L1660, except that some of the data are unknown at compile time (become known only at the time of target creation, so it can't just be a static const :-). -- 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
