Re: [Discuss-gnuradio] Proposed extensions for data networking

[Eric Blossom]

On Wed, Jun 07, 2006 at 02:06:21PM -0400, Michael Dickens wrote:
> 
> >>Why require m-blocks be the place where gr-graphs are called from?
> >
> >First off, nobody is forced to use the m-block stuff.  All the old
> >stuff will continue to work just as it does now.  That's part of the
> >reason for the strict separation.
> 
> Ahhh .... now I think I'm understanding better.  The m-block stuff is  
> much like the USRP ... knows nothing of GNU Radio, works  
> independently of GR, but is a module in the same way that gr-usrp and  
> gr-audio-xxx are.  The programming is entirely separate for the m- 
> block module, can operate separately from the current GR, much like  
> the USRP module can.  gr-mblock would be the "glue" understanding how  
> to operate gr-block's inside an m-block, and hence requires the  
> gnuradio-core libraries and headers for functionality.

Yes.

> Does the mblock module require knowledge of the USRP?

No.

> Or will there  be a mb-usrp module to handle that set of data transfers, much 
> like  
> there is a gr-usrp module for handling gr-block data transfers.

Yes.  We may refactor gr-usrp if there's common non-GNU Radio stuff
that might want to get pushed back into usrp.  The code that handles
endianness and packs and unpacks between the fixed point USB
representation and complex<float>'s comes to mind.

> So an mblock is provided with the packet and other meta-data to use  
> as it sees fit.  As the message makes its way through the m-block's  
> connections / ports, the data is transformed / processed / parsed /  
> etc... (see 4.8.4).  There is no explicit "output" port(s), but  
> rather these bi-directional ports which could be used as input-only  
> or output-only.  The data is transformed by creating new messages to  
> pass around?

Yes.

> 4.8.3:
> "• requires persistence as the message is processed by the radio
> • may contain elements that change as the message is processed in the  
> radio."
> 
> If I read this, w/r.t. your comments before, then some messages must  
> be kept around as they are processed (creating other messages, which  
> also might need to be kept around: "persistence"), while others can  
> have their internals changed during processing.

Yes.

> Also: An m-block can "contain" other m-blocks internally, or at least  
> that's what I now believe.  How are those internal m-blocks  
> scheduled?  Is there an internal "m-scheduler" which calls them in  
> their correct order?  Or does the encompassing m-block just "know" to  
> call them in order and deals with this itself?  Or some other way?

Composition of mblocks is for structural organization & complexity
management.  It does not imply anything about scheduling.  There is
one mblock scheduler that dispatches messages across all mblocks,
nested or not.

> >Note that in the BBN proposal there are no "graphs".
> >There are only mblocks, some of which contain other mblocks.
> 
> Ok, yes, a semantic difference really.  mblocks can be connected to  
> other mblocks, internally and/or externally.  Those connections must  
> be checked somehow, whether the terminology is "graph" or  
> "connection" or whatever.  It must be verified that the connecting bi- 
> directional ports are compatible (see 4.9.5 for that definition).

Agreed.

> So in 4.8.4 what is the "flow graph" as mentioned: "As a message  
> makes its way through a flow graph, the data is transformed by the  
> blocks along the way."  Since this is generic, I don't think it  
> applies specifically to the current gr_blocks and related flow- 
> graph.  If there is no m-graph, then those "flow-graph" references  
> should be changed.

Agreed.

Eric