The existing component implements the lightweight policy decribed here, and I made a modified version that does an endless task loop this morning. I can either check that one in as EndlessRetryPowerManagerP or just leave it as is for now until a use case for something like this comes up.
Kevin On Thu, May 1, 2008 at 3:51 PM, Philip Levis <[EMAIL PROTECTED]> wrote: > > On May 1, 2008, at 2:43 PM, Vlado Handziski wrote: > > > This is where the modular architecture of the power locks comes to play. I > think that the vanilla SplitControlPowerManager should retain a simple > policy of either ignoring the FAIL events / not releasing the resource to > the requester until it is sure that the device is on (a new request should > result in a new retry by the PM to start the device, etc.) That being said, > nothing prevent us from adding new policy in the form of a > RetryingXXXPowerManager that contains logic (either an endless task loop or > give up after N, etc.) to handle the retrying on behalf of the requester, so > whenever the grant is issued it is guaranteed that the device is on. > > > > Vlado > > > > > (cc'd to -devel) > > That makes a lot of sense to me. This would allow simple drivers where > there is no answer to FAIL to remain lightweight, while drivers that can > have run-time failures and may benefit from a retry can pay the cost of a > timer if needed. > > Phil > -- ~Kevin _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
