[Tinyos-devel] Request for comments on TEP 111

[Philip Levis]

On Nov 14, 2006, at 5:54 PM, Matt Welsh wrote:

>>
>
> 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.

OK. The approach is get/set for each field that just transparently  
provides access.

>
> 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?

I think that rather than go through the whole nx_struct description  
in 111, it might be better to note the salient points and refer to  
the nesC manual. I'm wary of reproducing text everywhere it's useful.

Regardless of alignment the structure is guaranteed to work. In  
practice, what nx_structs do is store values as arrays of bytes which  
are automatically marshaled/unmarshaled on each write/read.

>
> 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.
>

Fair enough. But please note: the TEP does not require that the  
packets be contiguous. It only specifies guidelines such that if it  
does need to be contiguous, you can make sure it is in a platform  
independent fashion. I tried to be very careful in the wording and  
use of MUST and SHOULD statements: is there text in the TEP which  
would preclude any of the above approaches.


>> 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.)

Good point. The goal of message_t is to preserve no-copy as much as  
possible, but sometimes that just isn't possible.


>
> 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.

They are.

Phil