Date: Thu, 29 Oct 1998 14:52:53 +0100 (CET) From: Andrzej Bialecki <abial@nask.pl> To: Bryan Mann <bmann@whistle.com> Cc: Terry Lambert <terry@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSF.4.02A.9810291441050.20293-100000@korin.warman.org.pl> In-Reply-To: <Pine.BSI.3.95.981028160517.12500B-100000@chaco.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Oct 1998, Bryan Mann wrote:
> Example states:
>
>
> INIT - perform initialization tasks
> START - to perform start-up tasks
> STOP - perform stop related tasks
> RUN - the primary work phase
> IDLE - for objects that are waiting on some external event
> CHECK - performs self consistency check
> useful to test config changes prior to commit.
> READY - ready to start but not yet started.
I have no comments to the above, but...
> UPGRADE - perform upgrade tasks
> DOWNGRADE- run downgrade tasks
If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think
that each object should have space for two sets of its parameters: one
currently used, and other, currently being supplied. This fits nicely to
our transactional model, because after you supplied new values, you didn't
change anything yet - first, you do a CHECK, and then COMMIT. If we assume
that old parameters are copied back to the "new" buffer, we can also
perform a ROLLBACK to restore previously used parameters.
> MONITOR - to connect for monitoring
>
> NOTIFY - out-of-band notification of state change
> [out-of-band notification means that the client
> opens a rendezvous point for the server to connect
> to upon completion of the STATE/object in question]
Hmmm... I wouldn't call them states - they are just one of (many)
parameters. In this case, if I set a parameter called MONITOR, the object
hooks up itself to some monitoring agent, but doesn't change its FSM
state. In fact, if it were to do it, it should be highly undesirable,
because ti would change its behaviour.
Similarly, NOTIFY is just a hook-up to send events to specified party.
> SHARE - actions to be performed when replicating this entry.
Hmph... I dunno I understand this in terms of a "state". This is rather
an action for specific event.
>
> EXT_{UserDefined}
> - user defined extensions but how do you specify
> where they go in the state machine ?
It depends on how the FSM is built into the given subsystem - I've seen
some FSM's which simply read their definition from configuration file
(Merit Radius is such an example).
Andrzej Bialecki
-------------------- ++-------++ -------------------------------------
<abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see:
Research & Academic |+-------+| "Small & Embedded FreeBSD"
Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/
-------------------- ~-+==---+-+ -------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9810291441050.20293-100000>