Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Sep 06, 2006 at 11:44:40AM -0400, Greg T. wrote:
README.modules that is basically tsort input. configure might even
check this somehow.)
[There’s been lots of discussion about that on other lists. The
problem ends up being that information is stored in duplicate places.
configure still needs to make it’s checks.]
One strategy is to put these files (after renaming to remove the bbn_
prefix and cleanup) in gnuradio-core.Then, after m-blocks arrive, blocks to handle tap/tun devices will
have to migrate someplace that can use m-blocks (gr-packet?).
I think that’s fine. With svn moving stuff isn’t the nightmare that
it is under CVS 
I think the big question is what kind of top-level structure to be
imposed on blocks intended for specific purposes. Perhaps a gr-phy
for things that sort of belong in the IEEE PHY layer makes sense, and
gr-mac.
Perhaps.
Perhaps README.modules can also contain the plan for what belongs
where.
Good idea. Once we figure it out
My general thinking (at this instant…) on top level components
(gr-usrp, gr-audio-oss, …), is that they exists because they have
additional dependencies that not everyone will want to fulfill.
At this point, some of the top-level partitioning is the result of
history. E.g., gr-gsm-fr-vocoder has no additional requirement beyond
gnuradio-core, and thus one could argue that it should be merged into
gnuradio-core.
Re tsort, it goes like this (ignoring external dependencies):
usrp gr-usrp
gnuradio-core gr-usrp
pmt mblock
gnuradio-core gr-mblock [gr-mblock doesn’t exist yet, but this is the
idea]
mblock gr-mblock
gnuradio-core gnuradio-examples [and some audio implementation]
gnuradio-core gr-atsc
gnuradio-core gr-audio-alsa
gnuradio-core gr-audio-oss
gnuradio-core gr-audio-portaudio
gnuradio-core gr-audio-windows
gnuradio-core gr-comedi
gnuradio-core gr-error-correcting-codes
ezdop gr-ezdop
gnuradio-core gr-ezdop
gnuradio-core gr-gsm-fr-vocoder
gnuradio-core gr-howto-write-a-block
gnuradio-core gr-radar
gnuradio-core gr-trellis
gnuradio-core gr-video-sdl
gnuradio-core gr-wxgui
Greg T. 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
Eric B. wrote:
gnuradio-core gr-audio-windows
gnuradio-core gr-comedi
gnuradio-core gr-error-correcting-codes
ezdop gr-ezdop
gnuradio-core gr-ezdop
gnuradio-core gr-gsm-fr-vocoder
gnuradio-core gr-howto-write-a-block
gnuradio-core gr-radar
gnuradio-core gr-trellis
gnuradio-core gr-video-sdl
gnuradio-core gr-wxgui
gnuradio-core gr-radio-astronomy
gr-wxgui (some parts of gr-radio-astronomy)
gr-wxgui (some parts of gnuradio-examples)
Johnathan C. wrote:
For “Release 3.0” we’re going to
…keep it this way and get the new organization cleaned up, fine-tuned
and out the door as tarballs.
-Johnathan