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 Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
