From 050f4b33a597e3cb804f89173359bce4dc898f2a Mon Sep 17 00:00:00 2001 From: gdt <gdt@221aa14e-8319-0410-a670-987f0aec2ac5> Date: Mon, 4 Dec 2006 18:19:59 +0000 Subject: Describe issues surrounding integrating BBN's 802.11 code. git-svn-id: http://gnuradio.org/svn/gnuradio/trunk@4051 221aa14e-8319-0410-a670-987f0aec2ac5 --- README.organization | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 README.organization (limited to 'README.organization') diff --git a/README.organization b/README.organization new file mode 100644 index 0000000000..15d9b24ff3 --- /dev/null +++ b/README.organization @@ -0,0 +1,34 @@ +[This file is currently not baked and does not claim to represent +consensus.] + +This file describes the current organization of the GNU Radio source +tree. It is intended to be both descriptive and normative. + +The big issues are: + +1) Should we separate by "code needed to implement protocol/modulation +foo", or related blocks. to (that are therefore not so likely to be +used together). + +2) How do m-blocks impact organization? If m-blocks are in a separate +module, which seems reasonable, then do we have most modules depend on +m-blocks rather than just core, or do we have two versions of blocks - +the classic continuous block and the m-block wrapped block? If +m-blocks become the main path, what will be less awkward? + +3) Because some (ADROIT at BBN) have proposed to implement MACs in +click instead of GNU Radio, should we have a clean separation of +MAC/PHY within GNU Radio, to facilitate using MACs implemented in +various places? + + +The immediate question is how to integrate the 802.11 implementation +done by BBN, available at: + + http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/gr-bbn/ + +This contains blocks at various places in the stack, and gdt believs +that putting them in an 802.11 module will lead to less reuse and less +of a tendency to generalize. + +[need pointers to existing documentation of big picture and what's where] -- cgit v1.2.3