[Tinyos Core WG] Boot Order

[Joe Polastre]

FWIW, Boomerang did have a solution to this problem; basically each
module was responsible for including the sub-modules that it used.
Each module was responsible for wiring its own initialization (rather
than the app user doing it) which means that the module that knew that
order of operation should be the one determining the init order.
There were lots of things that needed boot order (Deluge was a perfect
example).

See the uses of MainControlC for more examples.  It relied on nesC
assigning unique("") values in an increasing manner based on the order
of which unique was encountered during preprocessing by nesC.  Luckily
nesC was sane and did that.

http://tinyos.cvs.sourceforge.net/tinyos/tinyos-1.x/contrib/boomerang/tos/lib/sched/MainControlC.nc?revision=1.1.1.1&view=markup

There were, of course, discussions on this mailing list about this
exact topic over 2 years ago, but the powers that be chose not to
adopt such suggestions.

http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2006-March/002024.html
http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2006-March/002025.html

-Joe

On Wed, May 21, 2008 at 3:15 PM, David Moss <dmm at rincon.com> wrote:
> 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;
>
>   }
>
>
>
> }
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>