[Tinyos-devel] Request for comments on TEP 111

[Matt Welsh]

Wei,

Here are some comments on TEP 111.

1) Section 2 states that "This format keeps data at a fixed offset", but
this does not seem to be the case: different platforms with different
header sizes will have different offsets to the data field. This seems
to be an ambiguity of wording; I think the correct wording is "This
format keeps data at a fixed offset on a given platform". 

2) It is not clear why the metadata fields need to be nx_ types. These
fields are not sent over the radio, so there is no need for
endianness-matching on other processors; the extra overhead of using nx_
types for metadata access is not warranted. Some justification should be
given for this.

3) It would be very helpful to have some example interfaces for
accessing header/footer/metadata fields externally from the link layer.
The TEP mentions that implementations SHOULD provide such interfaces but
no examples are given. A reference to TEP 116 is given, but looking at
that TEP I don't see any concrete examples of interfaces to access the
link-layer header, footer, or metadata fields.

I think it would be useful to document a suggested approach to doing
this so we can avoid having every implementation adopt its own
conventions.

4) I am unclear on how the computation of the header offset will obey
word-alignment issues on certain platforms (e.g., the MSP430). In the
"getHeader(...)" example:
   
serial_header_t* getHeader(message_t* msg) {
  return (serial_header_t*)(msg->data - sizeof(serial_header_t));
}

There is no guarantee that the pointer returned here is word-aligned; it depends
on the alignment of msg->data as well as the size of serial_header_t. 
This issue will also arise on 32-bit platforms. I am concerned 
about the use of pointer arithmetic here -- if this is a non-issue perhaps 
the TEP can point this out or provide guidelines to implementers to avoid
common bugs.

5) Finally, what happens if this message_t format does not correspond to the
format expected by the underlying hardware? As an example, an implementation 
might need to set up structures for the hardware to DMA packets to/from the
interface directly, using a different layout than can be provided here. My 
guess is that this would require the implementation to copy to/from internal
structures. The assumption built into this TEP, however, seems to be that this
general format will be appropriate for interfacing to the hardware. The TEP might
want to clarify the assumptions it is making in this regard.

Matt



On Mon, 2006-11-13 at 20:54 -0800, Wei Ye wrote:
> Dear TinyOS developers and users,
> 
> I was asked to shepherd TEP 111 for TinyOS 2.0. In case you are not
> familiar with the TEPs (TinyOS Enhancement Proposals), they are the
> major technical documentation of TinyOS. They describe major OS
> abstractions and subsystems and source code documentation. For details,
> please check TinyOS website.
> 
> As a shepherd, my role is to collect comments and feedback from the wide
> developers and users, and help the authors to address these comments in
> revising the TEP. The TEP 111 describes the message buffer abstraction,
> message_t. Probably every TinyOS user is familiar with TOS_Msg, and you
> may have different experience on its limitations and how to work around
> them. The purpose of TEP 111 is to define a new message buffer structure
> to overcome these limitations. For details of TEP 111, please look at
> 
> http://www.tinyos.net/tinyos-2.x/doc/html/tep111.html
> 
> If you have any comments on TEP 111, you are welcome to email me and cc
> the above lists (which may trigger more discussions). Your feedback will
> help to shape the future directions of TinyOS.
> 
> Thanks,
> Wei Ye
> 
> 
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel