discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]