[Tinyos-devel] RE: CTP + LPL

David Moss dmm at rincon.com
Sat Feb 9 13:03:25 PST 2008 

I really like this discussion - there are very good points brought up from
all around on the process of development and documentation, and this was
certainly in need of talk.  I may be reiterating some thoughts other people
have already contributed, but here are mine.  I also offer two
recommendations on how we may move forward at the end.

In the past, members of core have contributed code and interfaces before
moving through a formal TEP acceptance process. This allows the code and
interfaces to be evaluated before being formally approved, and lets
technology move forward.  We see this with just about everything: from
CTP/dissemination, data storage, low power listening, everything.
Evaluation implementations and interfaces are created everywhere in the
TinyOS baseline before formal approval and finalization. But even after
formal approval, there's nothing to say that an interface is the best
interface or the best way of doing things.  The TEP's are simply a means of
providing information and some stability, be it good or bad. 

90% of our TEP's are Documentary, which describe everything functional in
the TinyOS baseline. TEP 1 defines very clearly what the types of TEPs are,
including Documentary: "Documentary TEPs describe a system or protocol that
exists; a documentary TEP MUST reference an implementation that a reader can
easily obtain. Documentary TEPs simplify interoperability when needed, and
document TinyOS service implementations."  

Getting the implementations in place before going through a long approval
process allows TinyOS the flexibility it needs as an emerging (and somewhat
experimental) embedded operating system.  Matt is completely correct in
bringing up the fact that TinyOS should be agile enough to move forward,
while balancing the stability required for its dependent user base.  Om is
completely correct in saying that the developers ~should~ keep their
documentation up to date, even though many - including myself - are guilty
of not doing so.  

The discussions within the core working group have been aimed at making sure
new interfaces won't cause instability. These discussions take place before,
during, and after the construction of any new functionality, and always
before any sort of formalized approval process. Going back to the CC2420
interface that started this conversation, discussions took place back in a
core working group meeting back in October 2007.  The resolution at that
time was to create a reference implementation in the stack to evaluate this
method before formally approving it as a requirement that all radio stacks
should provide.  Now that the interface has been implemented, we (meaning I)
should document it in a Documentary TEP, referring to the current
implementation.  The next step should be for users in the community to
evaluate whether or not this interface is really exactly what we need - if
it's not, we modify the TEP and the interface and move forward.  You can be
sure that this sort of volatility will continue for any interface and any
functionality in TinyOS until the TEP has been finalized, which could be
months or years down the road.  Yet, even after finalization, my
understanding is a future TEP can override the currently finalized TEP's,
which means no functionality in TinyOS is absolutely set in stone.  The
stability problem is guaranteed to persist.

TinyOS will constantly grow more interfaces and functionality from release
to release, regardless if the TEP's are keeping pace. 

My first recommendation to help mitigate this problem is to create a Best
Current Practices TEP describing how a users and developers should manage
his or her project with the goal of avoiding conflicts on top of a
constantly evolving open-source TinyOS code base.  It's doable: my team
manages several projects, each using different TinyOS baselines.  We've
constructed our systems so major conflicts will not arise, even when
upgrading to the latest random TinyOS snapshot.

My second recommendation is for all baseline driver and library developers
to maintain the latest information about their own implementations in the
TinyOS Wiki as a means of communicating to users what changes to expect when
updating their local baseline.  This comes down to personal drive and
willingness on behalf of the developer, but the wiki is probably the best
thing to happen to the TinyOS development process. Wiki documentation can
remain as flexible as the open-source implementations it supports, which is
mostly unlike our formal TEP process.  Expanding upon this, I believe the
CC2420 TEP I wrote should be done away with and turned into a set of wiki
pages which will allow the documentation to always reflect the latest radio
stack fixes and features.  I argue that TEP's should exist to help
developers decide which mandatory interfaces need to provided by their
implementations, not to constrain or reduce the set of functionality
provided by an implementation.

-David




-----Original Message-----
From: tinyos-devel-bounces at millennium.berkeley.edu
[mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Matt
Welsh
Sent: Saturday, February 09, 2008 6:12 AM
To: Omprakash Gnawali
Cc: TinyOS-Devel list
Subject: Re: [Tinyos-help] Re: [Tinyos-devel] CTP + LPL

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


_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

More information about the Tinyos-devel mailing list