[net2-wg] Fwd: Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

Okay, I can put that together.

About the locking, I am relatively indifferent, but I agree with you
that making each AMSender a client will be bloated. In my current
implementation, I expose the resource to 802154 senders but not to AM
senders. Miklos indicated that he wanted it exposed for other
protocols like FTSP, so maybe we should just add a thin non-generic
component under the AMSenders to handle the resource for normal AM
traffic.

Steve

On 7/6/09, Philip Levis <pal at cs.stanford.edu> wrote:
> On Jul 6, 2009, at 11:37 AM, Stephen Dawson-Haggerty wrote:
>
>> Just to check up on this, phil, have we given you what you need to
>> bring this up in core this week?  Once [if] they okay this, let's get
>> it checked in asap so we can start release testing...
>>
>> Thanks,
>> Steve
>> On 7/2/09, Omprakash Gnawali <gnawali at usc.edu> wrote:
>>>> - The SendResource will be shared by all clients of ActiveMessageC
>>>> and
>>>> Ieee154C. AMSenderC will be updated to use that. Any other client of
>>>> ActiveMessageC that does not use AMSenderC (e.g. FTSP or
>>>> TimeSyncMessageC clients) will have to call it directly. This is a
>>>> great bonus as it does not require all radio clients to pass through
>>>> AMSenderC.
>>>
>>> This will solve the current problem running FTSP+CTP?
>
>
> Core doesn't meet this week -- it meets next week. I will bring it up
> then. It would be nice if there were a clear, succinct, 1-page
> description of the proposal for core members to read before the meeting.
>
> One question -- is each AMSenderC a separate Resource client? This
> seems problematic. I think it will significantly increase code size
> (locking logic repeated across AMSenderC instances) as well as RAM
> (pointer as well as Resource queue entry for each AMSenderC). I think
> it would be better to keep the standard AM queue and make it a single
> client of Resource.
>
> Phil
>
>