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

[Stephen Dawson-Haggerty]

Just to jump back on this horse, here's some text about this proposal
I put together during when we would have been meeting:
http://jackalope.cs.berkeley.edu/~sdawson/link-proposal.txt

I hope we can use this as a base to explain to others what the need is
and what the changes are.

Om: is there a target date for the release?

Steve

On Mon, Jul 6, 2009 at 12:03 PM, Stephen
Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
> 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
>>
>>
>



-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720