sallai at isis.vanderbilt.edu
Wed Mar 11 13:00:26 PDT 2009
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?
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 :)
> 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.
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
More information about the Tinyos-devel