[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] module structure and m-block dependencies
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] module structure and m-block dependencies |
Date: |
Wed, 6 Sep 2006 16:35:43 +0000 |
User-agent: |
Mutt/1.5.9i |
On Wed, Sep 06, 2006 at 11:44:40AM -0400, Greg Troxel wrote:
>
> BBN's code to receive 1 Mbps 802.11 packets will shortly be eligible
> for merging in to the real repository (we've sent a signed assignment
> to FSF and are just watiting for a countersignature). In thinking
> about where to put it, I realize there's a bit of complexity.
>
> Eventually, many blocks will be m-blocks. Thus, the won't be able to
> be in gnuradio-core, since gnuradio-mblock depends on that.
>
> (If I'm confused about dependencies, it might help to have a
> 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