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

[Philip Levis]

Begin forwarded message:

> From: Janos Sallai <sallai at isis.vanderbilt.edu>
> Date: March 11, 2009 1:00:26 PM PDT
> To: TinyOS Development <tinyos-devel at millennium.berkeley.edu>
> Subject: Re: [Tinyos-devel] message_t
>
> 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