Re: [Discuss-gnuradio] module structure and m-block dependencies

[Johnathan Corgan]

Greg Troxel wrote:

> I think the big question is what kind of top-level structure to be
> imposed on blocks intended for specific purposes.

This is indeed an open issue I've been "silently dropping."

No thought went into organizing the new repository other than to combine
what already existed into one place.  We simply put all the
independently developed components at the root of the hierarchy, then
refactored the build system into a single master configure/recursive make.

"Dependencies" are handled by fixing the order of compilation. This
ensures that generated files in one component (like the core) are
available in the build tree when they are needed by later components.

This flat system works for now, but definitely does not scale. For
"Release 3.0" we're going to

So for the 802.11 stuff, I'd take the pragmatic step of first putting it
as its own top-level component, and we'd put it in the compile order
after mblock. I can help you do that.

Then, you can "at your leisure" begin refactoring bits and pieces of it
into prior components.  Some stuff you mention should go into the core.
 Maybe there are routines elsewhere that people have written you can
reuse, and eliminate some of the code you've done that replicates them.
Maybe some of your blocks are useful enough to be reused in other
projects and a separate component tree (like gr-packet as you mention)
should be created to house them.  But these are all things you can do
over time, while transparently preserving the outward functionality of
the 802.11 code in its own component module already integrated into the
build system.

Back to the bigger picture, though. I do think the combination of all
the existing components, as well as whats planned in the near future
(mblocks, 802.11, direction finding algorithms, radiopaging decoders,
new hardware, to name a few) calls for a re-think of how all of the G
NU Radio tree is organized and built.

We do (or will) have things like:

System and runtime: core, pmt, mblock

Core DSP stuff: fast math routines, filters, "piping", etc.

SDR/hardware drivers: usrp, ezdop, sdr1000

Audio drivers: alsa, oss, osx, windows, jack, portaudio

Additional DSP stuff: AM, FM, SSB, PSK, FSK, trellis, ecc, packetizing,
vocoding, etc

Networking: 802.11x

Specialty application areas: radio astronomy, direction finding, radar,
pagers

This does suggest a more hierarchical organization around these lines.

-Johnathan

signature.asc
Description: OpenPGP digital signature