[Tinyos Core WG] Meeting: 3/7

[Kevin Klues]

I may be late to the meeting today, so here are my comments on tep 116.....

1) This paragraph is unclear to me.

"A component can set the payload length with setPayLoadLength. As Send
interfaces always include a length parameter in their send call, this
command is not required for sending, and so is never called in common use
cases. Instead, it is a way for queues and other packet buffering components
to store the full state of a packet without requiring additional memory
allocation."

How exactly does this command help to accomplish the goal of storing the
full state of a packet?  I think it means that queues, etc. can tack on
packet specific state information to the end of a packets payload portion
instead of creating a separate structure for storing it.  What if the the
full payload is already in use, however.  I do not disagree that it is a
good idea to use this space if it is available, but how can it be guaranteed
that it is always there for use?

2) It may be worthwhile to mention somewhere how to actually set the AM
address (or is this documented elsewhere?).  If its documented elsewhere, a
reference to it would be nice.

3) The dispatch description in section 2.4 is unclear.  It also seems to be
just tacked on as an afterthought, since the opening paragraph in this
section doesn't even mention it.  Also, I'm not sure which level of dispatch
this section is actually referring to.  Is this section really trying to
just point out how dispatching could be implemented in general (without
tyring to force one to think about the ActiveMessage implementation of it)?
If so, this should be made clearer somehow, with emphasis put on the fact
that TinyOS enforces the use of ActiveMessaging.

What does this sentence mean exactly: "If a protocol provides a dispatch
mechanism, then each dispatch identifier SHOULD correspond to a single
packet format"?

Does it just mean that the packet format on top of which the dispatch
mechanism is built should be static?  An example of what NOT to do might be
appropriate here.

Kevin


On 3/6/07, Philip Levis <pal at cs.stanford.edu> wrote:
>
> Wednesday, March 07, 2007, 09:30 AM US Pacific Time,  Bridge: 4,
> Passcode: 9195717
>
> Numbers:
> US: 1-916-356-2663 or 1-888-875-9370 (non-Intel)
> UK: +44 1793 402663
> Denmark: +45 4527 5090
>
> Agenda:
>
> TEP 116 (attached)
> Debian packages
> I-Frame/T-Frame (TEP 125)
>
> Phil
>
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
>


-- 
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070307/7f109240/attachment.html