[Tinyos-devel] Re: CTP + LPL

[Vlado Handziski]

On Wed, Mar 5, 2008 at 8:17 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On Feb 9, 2008, at 1:03 PM, David Moss wrote:
> >
> >
> > 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.
> >
>
> Sorry for the delay, but...
>
> This is a great idea. It will also implicitly spell out guidelines
> for changing core systems, as those changes will have to follow the
> expectations the BCP spells out.
>

Yes, and this would be a nice place to document the CVS best practice
guidelines for the source tree:

http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2007-April/002904.html



> > 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.
>
> This is interesting -- it suggests that HALs shouldn't be put in a
> TEP, as they are open to evolution. It places a nice boundary on what
> interfaces are for TEPs and what are for less formal documentation.
>
>
I disagree. According to the HAA, the HAL interface, although chip/platform
specific,  is just as "public" as the HIL interface and needs to be
documented. It is true that the rate of evolution between the two is
different, especially given the periodic "discrete" jumps in the HIL
interfaces as they realign with the new typical HALs (so maybe they should
be kept in different TEPs), but ideally the HAL should be formally
documented as well, because it represents a supported and well defined "tap"
point for platform-specific code.

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