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

[Stephen Dawson-Haggerty]

On Mon, Aug 3, 2009 at 10:12 PM, Omprakash Gnawali<gnawali at usc.edu> wrote:
> Is it possible to have a more generic queuing on top of 802.15.4
> incase I want to run ftsp etc on top of 802.15.4?

Yes, it is possible.  This document doesn't say anything about the
Ieee154 stack above the mac layer.  I would, however, keeping the
amount of stuff we introduce for 2.1.1 at this layer very minimal
because I suspect (hope?) a lot of this will change with a real
802.15.4 stack and message_t discussion.

>
> "because one of the intermediate queuing and
> virtualization layers will manage this resource."
>
> -> is that AMQueue?

Probably, in the case of AM.

>
> In terms of schedule, lets still shoot for end of August for getting
> everything in place, and after some more testing etc. release in
> early-mid Sept.

Yes.  I should mention that blip is now feature complete for 2.1.1 and
ready to be checked into cvs and begin testing and validation, once we
add the modified radio stack.  I'm waiting for the okay on the
proposal to submit a patch implementing those changes for the cc2420;
the patch is ready to go.

Steve

>
> - om_p
>
> On Fri, Jul 24, 2009 at 1:36 PM, Stephen
> Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
>> 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
>>
>



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