Re: [Discuss-gnuradio] gnuradio flowgraph mechanism

[Eric Blossom]

On Mon, Feb 13, 2006 at 09:27:42PM -0800, Ges wrote:
> Hi Eric,
> 
> I am trying to rewrite the flowgraph mechanism written in Python
> into C++ so that I can run the GNU Radio modules written in C++ as
> such in the Click software router. But, as I started to work on it,
> i found that converting the code written in Python into C++ is not
> such a trivial exercise. So right now, all I want is to have a very
> simple flowgraph , so that I can try it with Click and run a graph
> of gnuradio modules.

A couple of observations: If you rewrite in C++ you will kill *all* 
support for hierarchical blocks.  If you rewrite in C++, every time
somebody makes a change to the python code, your rewritten code is out
of date / broken.

> Firstly, do you think this is the best way to do it? Implement the
> flowgraph in C++ and use that to run the gnu radio
> modules. Secondly, do you have any advise on implementing this
> flowgraph in C++? There is obviously a lot of functionality that I
> can avoid just to get a basic mechanism to run in Click.


> In short, all I would need to do is assign all the buffers for each
> block, and create the connections, and then call the run() function
> of the gr_single_threaded_scheduler. Am I right about this or am I
> missing something very crucial? As far as I understand the code,
> right now I can avoid the graph partition and the sorting mechansim
> as long as I use a very straight forward gnuradio module, which does
> not make any assumptions. I also feel that I can avoid a large part
> of the basic_flowgraph mechanism?

For a certain subset of graphs, what you're talking about will work (more or 
less).

If you don't partition, some applications will hang.
If you don't sort, cache locality for the buffers will suck.  There
could be other problems too.

If your real goal is to couple GNU Radio into Click, my suggestion is
to figure out a way to do it that doesn't require breaking the highest
level (most user leverage) parts of GNU Radio.  Why don't you just
embed python and be done with it.  Once everything is setup, the
python stuff stays out of the way.  This should definitely work for
user-mode click, but admittedly could be a stretch for kernel-mode
click.

I also offer a couple of heads up: the existing hierarchical block
implementation will definitely be revisited (and modified) -- it's got
some warts on it that need fixing -- and the conversations about
handling variable length packets will probably lead to changes in the
flow graph / scheduler.

John's ideas about an XMLish fix might work.  I'm not sure what you
would do about dynamic reconfiguration, or what it takes to hold onto
references that correspond to the signal processing blocks.  We often
send messages to or invoke methods of the blocks after instantiation.

Eric