Re: Remaining problems in firewire-net

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

On Nov 15 Maxim Levitsky wrote:
> That is because 1394 spec specifies that first of all the ISO channel
> must be allocated from the IRM node. The firewire stack currently just
> uses hardcoded numbers in two places the ISO is used 
> (firewire-net, and firedtv)
> However it has all functions implemented for this.

This is a bug (missing feature) in firedtv but not in firewire-net. The
broadcast channel is allocated and reallocated by the bus manager, not
by an IP-over-1394 user.  But you found that out already, below.

Channel allocation and DMA context allocation and control are unrelated
issues, on the other hand.  One is a higher-level cooperative protocol
for bus-wide resource management (in which the nodes' roles are defined
in various different ways by protocols such as AV/C's CMP or by IIDC).
The other is about hardware control locally in the OHCI bus bridge
hardware.

[...]
> In case of firewire-net, it is simpler, because it uses the broadcast
> channel, so it only has to find who is the IRM and read its
> BROADCAST_CHANNEL.
> 
> However, I think I need to write a function to query the IRM its
> broadcast channel, don't think it has one.

Overkill.  Just leave it as is:
  1.) We know which number the broadcast channel has.
  2.) We optimistically assume that a 1394a compliant IRM or bus
      manager exists and allocated that channel.

Why introduce entirely unnecessary fragility?

> Speaking of IRM discovery, the spec says it should be a node with
> contender bit and largest node id. However, the code in
> core-topology.c, build_tree seems to take the node that sent the
> selfID packet last.

This is because of a monotony rule of how self ID packets arrive during
self identification phase.
-- 
Stefan Richter
-=====-==-=- =-== -====
http://arcgraph.de/sr/