[Tinyos-devel] Request for comments on TEP 111

[Matt Welsh]

> Your conclusion is correct. Which wording do you think is clearer:
>
> This format keeps data at a fixed offset on a given platform
>
> or
>
> This format keeps data at a fixed but platform dependent offset

I prefer the former - seems less ambiguous.

>>
>> 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.
>>
>
> There is an example in CC2420Packet in chips/cc2420.
>
> Can you be a little clearer on what you imagine the intent of this  
> text to be? Is it to give guidelines on what to name the commands/ 
> events? That is, by "conventions" do you mean naming conventions?  
> Or are you also thinking about whether you return parameters  
> through pointers, etc? I agree that adding a bit more information  
> would be helpful, I'd just like to get a sense of what information  
> you think is most important.

I guess what I had in mind was just an example of what an interface  
to the header/footer fields would look like, mainly by way of  
suggesting a possible naming and parameter-passing convention. For  
example, should the interface take a message_t* as an argument and  
return an *offset* to the appropriate field, or should there be  
separate get/set methods for each field? Would those methods do any  
form of error checking (i.e., ensuring that a set value is in range  
for the link layer, etc.) or just transparently provide access to the  
packet field? These are important design considerations and it would  
be nice to have some consistency across link layers.

> One of the advantages of nx_structs is that they do not care about  
> alignment (this lets them be network types). The cost is that you  
> access words as individual bytes. Hence the comment that if you  
> need to do serious processing you should copy to native types.  
> David Gay had an intern evaluate the performance of this approach  
> (when he was trying to figure out whether one-time marshaling/ 
> unmarshaling or in-place modification was preferable), which showed  
> that the cost is negligible.

Perhaps this bears explaining in the TEP, so an implementor of the  
proposed interface knows whether they need to be concerned about  
this. For example it would be unfortunate if someone implementing  
their own message_t header/footer decided to add in redundant padding  
bytes. I don't really know how nx_structs are implemented; when you  
say "they do not care about alignment", does this mean that  
regardless of the alignment of the structure in memory it's  
guaranteed to work?

> How would a message_t format not match what is expected in hardware?

Lots of ways: for example if the payload and header are not  
contiguous in memory, such as if the hardware uses a separate  
descriptor ring for headers. Other hardware devices might not place  
the "header" physically before the data payload, or might use a  
header structure that would be too large and unwieldy to include in  
every message_t, but which could be generated on the fly for each  
message being transmitted. I just think we want to not be too short- 
sighted about this possibility.

> message_t doesn't specify the data layout: it is really only an  
> allocation structure.

That's perfectly fine; perhaps the TEP should make that more clear so  
that an implementor realizes there is some flexibility in how this is  
implemented. (For example, if a given hardware device needs something  
different than what message_t provides, the implementor MAY implement  
the link layer software to marshal the message_t structure to and  
from underlying hardware structures.)

Keep in mind I'm reading the TEP as someone who has done protocol and  
device driver hacking on other systems (not just TinyOS messaging)  
and I am also unfamiliar with the innards of the current CC2420 radio  
stack. That's why I think these clarifications may be useful.

Matt