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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > > > > > > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
