[Tinyos Core WG] Boot Order

[David Moss]

I've run into this problem several times now, so I wanted to bounce an idea
off you guys.

 

The problem is I have an application that consists of many, many sub-systems
and components.  The sub-systems work fine when they are separated, but
integrating them together can cause problems with the order they are
started. 

 

Specifically, the problem is with Boot.booted().  There's a single event
signaled out to fire up the entire system, but the fan-out here is dependent
upon the order in which I pull in components within a configuration.  If my
main configuration lists all of the components that comprise the system in a
certain order, and those components all use Boot.booted() to startup, the
order that their booted() events get signaled is dependent upon the order I
listed them.  In fact, by changing the order in which components are called
out in a configuration file, the entire behavior of the system could change
because something started up before a sub-system it is dependent upon.
Sometimes these types of integration issues are nearly impossible to debug.

 

A good example of this boot order behavior is loading variables from
non-volatile memory. I have a component that reads from internal
microcontroller memory to instantiate variables within other modules in the
system.  This component has to boot() before the rest of the system tries to
start and access those variables.  My solution in the past was to add a
custom init() command to MainC to start this non-volatile configuration
module before the rest of the system.  

 

I think that a single Boot.booted() interface is not enough for more
advanced applications.  I'd like to see several Boot interfaces provided,
each specifying a different priority, like 1-5 (where 1 is the highest
priority).   This would allow components to startup in a predictable manner
without bloating code.  We could keep the MainC signature the same for
backwards compatible, and create a BootC configuration to provide Boot
interfaces renamed to something like BootPriority1, BootPriority2, etc. and
the lowest priority could be the standard Boot.booted().  

 

The same argument could apply to the Init interface.  Right now we have two
priorities on that: the PlatformInit and SoftwareInit.  I'm not sure that
adding more Init priorities is as compelling as fixing the Boot interface
though.

 

 

For me, I'd like my system to boot in this order:

 

The highest priority component would be something like my non-volatile
variable loading component and other non-volatile memory drivers
(configurator). These need to instantiate variables from flash for the rest
of the system.

 

Second, configure the radio settings (low power communications, channel,
output power, etc.), and other higher priority things like file systems.

 

Third, enable communications on radios or serial.

 

Fourth are any application dependencies, drivers, custom stuff, etc.

 

Finally, the application boots.

 

 

 

All other operating systems I know have a defined order in which elements
boot up, and I think TinyOS would benefit from the same.  Getting rid of the
boot order based on the order of compilation is critical to handle these
more complex integration issues.

 

Just a thought. 

 

-David

 

 

 

configuration BootC {

 

  provides {

    interface Boot as BootPriority1;

    interface Boot as BootPriority2;

    interface Boot as BootPriority3;

    interface Boot as BootPriority4;

    interface Boot as BootPriority5;

    interface Boot;

  }

  

}

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080521/4efc0ece/attachment.htm