Date: Thu, 29 Oct 1998 23:43:50 +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.9810292331170.3317-100000@korin.warman.org.pl> In-Reply-To: <Pine.BSI.3.95.981029090042.13332A-100000@chaco.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Oct 1998, Bryan Mann wrote: > On Thu, 29 Oct 1998, Andrzej Bialecki wrote: > > > On Wed, 28 Oct 1998, Bryan Mann wrote: > > > [deleted] > > > UPGRADE - perform upgrade tasks > > > DOWNGRADE- run downgrade tasks > > > > If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think > Hmmm, no I really meant upgrade/downgrade as in a short list of things > that the code might be able to do if told to enter that state like > service manager/bootstrapper says enter state UPGRADE then service does: > a) listen on port 6060 for tar ball > b) after receiving tar ball and md5 checksum check package > c) deinstall old package saving away that copy > d) install and verify new package > e) enter state IDLE or READY Ah, you meant something like a field-upgrade! Nice idea. Nonetheless, I'd treat it as certain action, though it can be so lengthy as to justify a separate state. I've been thinking about it just after I sent the last version of UCI document. I need to make more clear the distinction between a state and an action. I think the FSM could be reduced to very few states, namely: * INIT * CHECK (this is really an action, but it can be lengthy) * READY * STARTUP * SHUTDOWN * RUN * IDLE (blocked) * BUSY - performing some non-interruptible task (such as software version upgrade) * ERROR The rest would be actions, and each object would have to implement some minimal set of actions. > But you are correct we do need COMMIT and ROLLBACK as you have described. > Perhaps it doesn't make sense to think of putting a sub-system/service > in UPGRADE or DOWNGRADE state. The BUSY state will serve this role. > > 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). > > That would be very good. Now, when I come to think about it... Perhaps FSM would be pretty standard, but the set of actions and events implemented in each object would be different.. Then the actual implementation would define these sets (possibly basing on some user-settable parameters), and one of mandatory actions would be to return the list of actually provided services/parameters' tree. > Thanks for listening. Hey, thank you for interesting ideas! :-) 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.9810292331170.3317-100000>