start phases

[Ulf Wiger]

Since the dependencies are specified in a key-value list,
one could of course add other options.

One such option could be to await a globally (or locally)
registered name. But I'm not actually convinced that it
adds much. The start phases are quite powerful, in that
they map to a function, and you can have as many as you
want in each application (well...;)

One thought was that it could reduce the need to have
included applications. We've found that while creating an
applciation hierarchy allows you to synchronize a lot of
complex activities during startup (and also simplifies
takeover), they're a pain to manage, and it's very difficult
to add included applications to an already released
application.

Introducing start phase dependencies could allow us to build
much more modular and extensible systems.

As an extension of the work, I think the application_controller
should be completely re-written (sorry Martin ;). The whole
permit_app() thing should go away entirely (does anyone actually
use that?) It severely clutters up the code and could be
accomplished by hooking into the message passing API to the
application_controller (which came much later.) In general, the
AC implements several different functions in the same process,
which makes it difficult to understand and modify.

/Uffe

Den 2005-03-03 19:53:34 skrev Taavi Talvik <taavi@REDACTED>:

> On Thu, 3 Mar 2005, Ulf Wiger (AL/EAB) wrote:
>
>> The idea is that we should be able to extend the start phase concept
>> significantly, and get cleaner (and perhaps faster) execution of complex
>> system start sequences.
>>
>> While you can still specify dependencies in the 'applications' attribute
>> as before, you can now also specify dependencies for each start phase,
>> like so:
>>
>> {start_phases, [{Phase, Arg, [{run_before, [app() | phase()]} |
>>                              {run_after, [app() | phase()]}]}]}
>
> Look at FreeBSD(NetBSD?) startup scripts. They are shell scripts,
> which have keywords in first fiew lines. On the startup keywords
> are extracted and topologically sorted. Then they are executed in
> appropriate order.
>
> Example:
>             #!/bin/sh
>             #
>
>             # REQUIRE: networking syslog
>             # REQUIRE: usr
>  	   # BEFORE: LOGIN
>             # PROVIDE: dns nscd
>             # KEYWORD: FreeBSD
>
> man rcorder(8) rc(8) etc.
>
> Just having run_before/run_after are probably not enough.
>
> best regards,
> taavi
>
>



-- 
Använder Operas banbrytande e-postklient: http://www.opera.com/m2/