From owner-freebsd-small Tue Oct 6 06:23:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA15084 for freebsd-small-outgoing; Tue, 6 Oct 1998 06:23:54 -0700 (PDT) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14979 for ; Tue, 6 Oct 1998 06:22:54 -0700 (PDT) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id PAA13055; Tue, 6 Oct 1998 15:26:01 +0200 (CEST) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Tue, 6 Oct 1998 15:26:00 +0200 (CEST) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: James da Silva cc: Mike Smith , FreeBSD Small Subject: Yet another configuration model (long) In-Reply-To: <199810051918.PAA21621@torrentnet.com> 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 Mon, 5 Oct 1998, James da Silva wrote: > It seems to me that the basic goal here for picoBSD is to be able to > configure the whole thing from one script file, including perhaps some > extensibility (which IOS does not have). Yes, that was my goal when I started this discussion... > But that's not the problem. The problem is the mapping from this small > simple script-based language onto the "real" configuration base of the > system. This can bloat up in a hurry. Yes, that's the main problem. I proposed Forth as an alternative to /bin/sh, because it's smaller and more flexible _for_writing_programs_, not as a user shell per se. Anyway, still the main problem is the structure of the (single) config file, and its relation to UI and existing config files, which are often application-specific (but large part of them is not). My idea was to keep and change the config basing on a single file, and then regenerate needed files on the fly. But I have yet another idea how this could be done... Read on. > Eg, does each subsystem read from the config file, or is there a single > command shell that updates some registry (ldap and agentx spring to mind > for the registry)? Either way, you have to modify all your programs to get > their config info from this centralized place. Or, if you don't want to do It depends on the type of the system. In some cases, all you have to do is just to ifconfig, add static routes and off you go. Besides, we still need (IMVHO) to write more picobsd-ified versions of standard system utilities - making them compatible with the new config scheme would be simple then. > that, you can have your script processor generate the traditional conf > files. The mapping can be complicated if you aren't careful. > > If forth is being considered as way to implement a lot of the > non-performance critical "glue" code, and not necessarily as the interface > through which the admin operates, then that's less controversial. Performance of Forth programs is _way_ better than that of normal shell scripts, at least that's what people say... > > Wouldn't Java or some other bytecode language be similarly compact, or at > least in the same ballpark? I know, a typical java runtime, like tcl, is > bloated; but how much of that is necessary? How big would a simple JVM > with only the basic classes be? I highly doubt you could beat Forth when it comes to resource consumption (not only static size, but also RAM footprint). Unless you can share with us your (free) implementation of the JavaCard standard... :-) But as you noted above, the main problem lies not in the tool with which we write the "configurator", but in its interaction with multiple config files needed by various programs. As a side note: Not long ago I implemented in Java a flexible hierarchical configuration database, where you could store and retrieve device parameters just like this: String loc; Base base=new Base(10); Base b; // Store an object in database. 3rd param. is a type name. // This also does an equivalent of mkdir -p /main_db/devices/UPS/UPS1 base.put("/main_db/devices/UPS/UPS1/location","Main building","String"); b=base.chdir("/main_db/devices/UPS1"); // Retrieve the object. I can also check its type using Base.getType() loc=b.getString("location"); b=b.chdir("../"); // List available keys for( Enumeration e=b.keys(); e.hasMoreElements(); ) { ... } etc, etc... I can imagine something similar to store and change parameters for FreeBSD subsystems (this is what I meant by saying "a config database"), other issue here is something what Java people call "serialization", i.e. changing this database to a flat file. Yet another issue is when exactly the change of a parameter affects running configuration. The "configurator" should monitor what changes were made, and be able to restart appropriate services. And now, for the really wild idea... :-) Yet another idea occured to me: it's also possible to view "the configurator" as a "service (daemon) providing its clients necessary configuration data". In this model, the database could be stored in some internal format known only to the config daemon, and converted on the fly when it receives a request from some client to supply config data. Of course, all programs would have to be converted in order to make calls to the config daemon on startup, register with him to receive notification when configuration changes or when the service should be stopped. Some general aspects of the system (such as ifconfig, static routes, hostname) could be performed by the config daemon itself. Hopefully, one could hide most of the gory details in some library which would translate ordinary calls to read the config file, to calls to the config daemon. Now, what do you think of it? Go, you can laugh at me... ;-) 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