[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

Hi--  We've been discussing the changes necessary to the radio stack
for blip; let me finally provide a concrete proposal.  Is this
acceptable to everyone?

Goal: add ability to send/receive from multiple "networks", as
determined by the "network" dispatch byte in a TinyOS IFRAME.
Motivation: the network byte may become assigned by IANA in the
future.  We should be able to support new network protocols expecting
to receive packets dispatched on this byte.
Proposed additions: add three parameterized interfaces as system-wide
networking abstractions:

    interface Resource[uint8_t clientId];
    interface Send as NetworkSend[uint8_t networkId];
    interface Receive as NetworkReceive[uint8_t networkId];

Sample patch for the cc2420 is attached.  This is not meant to be
committed, since it will break if TFRAMES are used and is not
well-tested.

Just like in the AM layer, we need resource sharing between different
senders.  However, I am loathe to add another layer of buffering since
most existing code assumes it "owns" the radio and does its own
buffering-- both blip and the AM stack do this.  The lightest-weight
solution seems to be adding a Resource lock around the radio; with
FCFS it will be reasonably fair.

Changes to AM: the resource request/release calls are added to
CC2420ActiveMessageP, so the semantics of using AMSend do not change.
Active Messages become just another "network" but the interface change
is encapsulated so there shouldn't be any broken code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tinyos.radio.patch
Type: text/x-patch
Size: 8309 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/net2-wg/attachments/20090628/f5522dec/attachment.bin