[Tinyos Core WG] Fwd: [Tinyos-devel] message_t

Philip Levis pal at cs.stanford.edu
Tue May 5 23:12:16 PDT 2009



Begin forwarded message:

> From: Jan Hauer <jan.hauer at gmail.com>
> Date: March 12, 2009 7:31:48 AM PDT
> To: Janos Sallai <sallai at isis.vanderbilt.edu>
> Cc: TinyOS Development <tinyos-devel at millennium.berkeley.edu>
> Subject: Re: [Tinyos-devel] message_t
>
> This proposal didn't support buffer swapping, so you'd have to copy
> the payload before forwarding. To be compatible with AM you'd also
> have to copy into message_t (we always thought a single copy would be
> ok). But if the proposal was adapted to use a ring buffer instead of
> the (still) fixed message buffer layout then copying might not be
> necessary... I'll adapt the proposal and distribute an updated version
> in the next email.
>
> Jan
>
>
> On Wed, Mar 11, 2009 at 9:00 PM, Janos Sallai
> <sallai at isis.vanderbilt.edu> wrote:
>> Jan,
>>
>> I just quickly skimmed through the writeup. I have two questions:
>>
>> 1. If there are different message structures on the transmit and
>> receive paths, how can we do bridging without buffer copying?
>>
>> 2. How would it be possible, with the proposed message abstraction,  
>> to
>> provide an AM compatibility layer?
>>
>> Janos
>>
>> On Wed, Mar 11, 2009 at 2:36 PM, Jan Hauer <hauer at tkn.tu-berlin.de>  
>> wrote:
>>> Attached is a proposal for an alternative message buffer abstraction
>>> that allows variable-sized protocol headers/footers, but still uses
>>> static allocation of the message buffer. We have not discussed  
>>> this in
>>> detail, so ... go on and take it apart :)
>>>
>>> Jan
>>>
>>> On Wed, Mar 11, 2009 at 6:53 PM, Philip Levis  
>>> <pal at cs.stanford.edu> wrote:
>>>> As developers have started implementing standards on TinyOS,  
>>>> message_t
>>>> has started to show some limitations. The goal of message_t was to
>>>> allow software to pass messages between different AM link layers
>>>> without copying, and this involved several simplifying  
>>>> assumptions. As
>>>> systems need more complex link layers (e.g., more than one 15.4
>>>> addressing mode, security support, IPv6 on top of 15.4), some of  
>>>> the
>>>> design decisions have started to become problematic.
>>>>
>>>> For example, message_t requires that the header, data, and footer  
>>>> be
>>>> allocated separately. Depending on your 15.4 addressing and other
>>>> options, the header can be anywhere from 3 to 30 bytes or so.
>>>> Correspondingly, the payload can be anywhere from 120 to 95 bytes  
>>>> or
>>>> so. While the two of them have, in combination, a maximum length
>>>> (125), you have to allocate the maximum of each of them separately,
>>>> leading to about a 20% waste (150 bytes).
>>>>
>>>> This has led core to start looking at other message abstractions.  
>>>> It's
>>>> important to note that changing the underlying buffer abstraction  
>>>> used
>>>> by radio drivers does not mean we have to break AM-based software
>>>> compatibility: many of these issues are arising exactly because  
>>>> TinyOS
>>>> needs more than just AM. At the worst case, you just make a single
>>>> copy between the AM layer (message_t) and other buffer abstraction
>>>> that drivers and other stacks use.
>>>>
>>>> Jan (TU Berlin) is going to send out one proposal he's come up  
>>>> with.
>>>> Stephen (Berkeley) also has some thoughts, and I encourage  
>>>> everyone to
>>>> examine the proposals. This is hopefully something that will change
>>>> for 2.1.1, or if more involved than anticipated, maybe a later  
>>>> version.
>>>>
>>>> Thanks,
>>>>
>>>> Phil
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> Tinyos-devel at millennium.berkeley.edu
>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>
>>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel



More information about the Tinyos-2.0wg mailing list