[Tinyos-devel] LPL API for protocols

[Vlado Handziski]

On Mon, May 19, 2008 at 9:29 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On May 19, 2008, at 11:36 AM, Vlado Handziski wrote:
>
>
>>
>> I am trying to understand if there is any benefit from tunneling these
>> control interfaces all the way to the AM components. Traditionally we have
>> been using the packet metadata as a blackboard that help us pass this kind
>> of information between the different components of the stack, without
>> forcing us to settle on a fixed composition or layering. Moving away from
>> this approach will make things more simple but at the same time it will
>> constrain the freedom to experiment with composition. In this sense, I agree
>> with your conclusion that fixing the current LPL control interface is
>> probably the best way to proceed.
>>
>
> Vlado,
>
> Don't forget that AMSenderC virtualizes the AM abstraction; only its
> underlying implementation knows which client has a packet pending. I think
> it's much cleaner for a single component to provide the necessary interfaces
> than to spread them across multiple components; there are cases where this
> occurs (e.g., SplitControl is on ActiveMessageC, not AMSenderC, for good
> reason), but AMSenderC is a virtualization of ActiveMessageC, nothing more.
>
>
I was not trying to make a distinction between ActiveMessageC and AMSenderC,
by AM components I meant all those that export AM interfaces, virtualized or
not. I was just trying to understand the value is from coupling this so
tightly with the data path at this level, since I really expect that most of
the fiddling with per-packet settings will be done by some logic integrated
in the stack / thus not being of much interest for the normal users of the
AM interfaces.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080519/c99b5817/attachment.htm