[Tinyos-help] Re: [Tinyos-devel] CTP + LPL

[Matt Welsh]

The problem with this approach is that folks generally won't update  
all of the TEPs for each release so I expect there will be a lot of  
drift. Also, the TEP approval process is currently very lengthy. As a  
result the code will inevitably be released before the TEP has been  
finalized, and indeed during the TEP review there may be issues raised  
which cause the TEP to be changed and require changes to the  
corresponding code as well.

As I understand it, the point was that you're supposed to get things  
approved in TEPs *first* (so everyone agrees on the interfaces and  
functionality) and *then* go write the code. Usually we do it the  
other way around and the TEP approval ends up being a rubber stamp on  
whatever happens to be in the code.

Of course, documentary TEPs may be different than "regular" TEPs, but  
I don't quite understand the difference.

It is clear that there is a tension between wanting to innovate  
rapidly on one hand and maintain a formal procedure for vetting of  
interfaces and code on the other. I'm not sure how to resolve this. It  
would be unfortunate if we allowed the TEP process to slow down  
progress on the code. At the same time with increased user base we  
need some way of maintaining stability. Personally, I've never been  
convinced that a heavyweight TEP process is the right way to do this  
given the small size and relatively tight-knit nature of the TinyOS  
community. The Java Specification Request (JSR) process is similar to  
TEPs but I think we would all agree that the Java community is much  
larger and has many, many more players with competing interests. We  
should be able to be much more agile.

On Feb 9, 2008, at 12:36 AM, Omprakash Gnawali wrote:

> I think each documentary TEP refers to the release version number so
> even if the interfaces get added to the head of the CVS, I don't see
> that as a problem. In theory, such interface change will be discussed
> when a new TEP is written to document a new release. This brings up
> another point - when we are getting ready for a release, we should ask
> the authors of each TEP to review their TEPs and potentially provide a
> new TEP to obselete the old TEP.
>
> Does this mean TEP has to be, ideally, community reviewed before we
> release a particular piece of code?
>
> - om_p
>
> On Feb 8, 2008 12:45 PM, Vlado Handziski <handzisk at tkn.tu-berlin.de>  
> wrote:
>> I fully agree, and the question is not philosophical.  The TinyOS HAA
>> defines two well-defined taping points for the application into the  
>> driver
>> code: the HAL and the HIL level. Consequently, the public  
>> interfaces at both
>> the HAL and the HIL level have to be documented and accepted  
>> through the TEP
>> process before becoming part of the core.
>>
>> As long as the proposed change is a part of the HAL level CC2440  
>> public
>> interface, the above rule applies.
>>
>> On the technical side, historically we have been very conservative in
>> exporting signals from the radio stack that can bring the stack to  
>> a halt if
>> misused. In TinyOS 1.x there was a similar event used for time
>> synchronization that caused a lot of problems because ignorant  
>> users were
>> attaching long running operations to it.
>>
>> Vlado
>>
>>
>>
>>
>> On Fri, Feb 8, 2008 at 8:41 PM, Matt Welsh <mdw at eecs.harvard.edu>  
>> wrote:
>>> One of the interesting aspects of NesC is that it doesn't enforce  
>>> any
>>> specific kind of encapsulation of interfaces. That is, an  
>>> application
>>> component can "poke through" the various layers below it to get at  
>>> an
>>> interface provided by a deeper underlying component. In this case  
>>> you
>>> propose to provide a CC2420-specific signal when a message is  
>>> about to
>>> be transmitted. I don't see a problem with that but I am concerned
>>> about the divergence of the implementation from the TEP, and what it
>>> means for layering in general (for example, above other, non-CC2420
>>> radio stacks).
>>>
>>> One of the oft-mentioned problems for non-core developers is that
>>> changes like this are introduced without being well-documented,
>>> leading to a tangled mess of interfaces, and potentially unexpected
>>> behaviors. My understanding was that the TEP process was intended to
>>> reign in that sort of volatility, no matter how expedient the change
>>> might be. So I guess this comes down to a more philosophical  
>>> question
>>> of which changes to a core system component require vetting through
>>> the TEP process and which do not.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Feb 7, 2008, at 7:13 PM, Philip Levis wrote:
>>>
>>>>
>>>> On Feb 7, 2008, at 6:00 AM, David Moss wrote:
>>>>
>>>>> Matt and Phil -
>>>>>
>>>>> This is meant to serve only as a private interface within the
>>>>> CC2420 stack
>>>>> right now, not an interface provided by the ActiveMessage façade.
>>>>> After
>>>>> all, once the interface is provided by ActiveMessage, it is no
>>>>> longer a
>>>>> private CC2420-specific interface.
>>>>>
>>>>> This is absolutely not a CTP or MultiHop protocol changing
>>>>> interface, since
>>>>> that would make those libraries platform dependent, which is bad.
>>>>> This is
>>>>> also not an LPL interface. Rather, the point of this interface is
>>>>> to simply
>>>>> signal an event at the top of the stack that says the radio is
>>>>> sending a
>>>>> message. Your application can do what it wants with that event.
>>>>>
>>>>> For developers who want CTP + LPL on a CC2420 platform, this  
>>>>> single
>>>>> notification event gives them the ability to make it happen *right
>>>>> now*
>>>>> without modifying any libraries.  No modifications to CTP, no
>>>>> modifications
>>>>> to LPL, no modifications to the radio stack, and nearly 0 cost.
>>>>>
>>>>> You're correct: we should document this interface in the CC2420
>>>>> TEP, or add
>>>>> this to some other TEP to standardize it across radio stacks.  A
>>>>> second
>>>>> direction would be to continue adding onto the LowPowerListening
>>>>> interface
>>>>> to make each outbound message use your local LPL settings, but I
>>>>> would be
>>>>> hesitant to make those kinds of changes without a lot of backing.
>>>>>
>>>>>
>>>>
>>>> Oh, I think I misunderstood. I thought you were suggesting a change
>>>> to the CTP code in CVS.
>>>>
>>>> Phil
>>>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> Tinyos-help at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel