From owner-freebsd-small Thu Oct 29 05:48:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA24624 for freebsd-small-outgoing; Thu, 29 Oct 1998 05:48:08 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl ([148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA24615 for ; Thu, 29 Oct 1998 05:48:05 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id OAA07577; Thu, 29 Oct 1998 14:52:54 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 14:52:53 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -------------------- ++-------++ ------------------------------------- ||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