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

[Omprakash Gnawali]

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?

"because one of the intermediate queuing and
virtualization layers will manage this resource."

-> is that AMQueue?

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.

- 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
>