Date: Tue, 28 Jan 1997 08:38:37 -0500 From: Bakul Shah <bakul@torrentnet.com> To: Warner Losh <imp@village.org> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, chat@freebsd.org, config@freebsd.org Subject: Re: Kernel config metasyntax Message-ID: <199701281338.IAA11782@chai.plexuscom.com> In-Reply-To: Your message of "Mon, 27 Jan 1997 21:29:43 MST." <E0vp5B1-0003Cu-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> (option 'DDB :description "blah" :type 'boolean) > (option 'DDB_PANIC_REBOOT :description "blah blah" :type 'boolean > :depends-on 'DDB) > which would be just a simple eval in lisp :-) (-: :-) > However, no matter what the language, I'm all for doing things as > easily as possible, and if that is TCL, then go for it. As you may > guess, I've been left with a bad taste in my mouth for TCL over the > years, so I tend to react negatively to it. If others thing that it > is the way to go, and they are the ones writing the config tools, then > my likes and dislikes really don't matter. I am with Warner on this one. Syntax of a language is the least of one's worries (except when it gets in the way). The hard part is pinning down consistent semantics. Also, languages tend to grow and its uses evolve. Someone else may have to extend it later. For all these reasons, whether one uses YACC+C or TCL or Lisp or Prolog, it would make sense to first define the semantics: - What do you want the config language to be? - What objects and relationships should it describe? (e.g. busses, IO-devices, drivers, parameters, subsystems ...) - Can the language describe the *complete* set of objects and relationships for existing configurations? - Can you come up with rules that future configurations are *likely* to fit in? For example, rather than enumerating all the possible objects of interest, can you come up with a `type' object and ways to define new types? - Do you need to embed bits of C code (e.g. for generating param.c, config.c, ioconf.c) or do you need to use some `magic' rules? - Can the language be `declarative' as opposed to `algorithmic'? The former is easier to use, the latter easier to implement. - Can you make do with a smaller language? Can an existing language be used as a starting point or base? One doesn't have to be formal/anal about this process but it helps to be aware of it. At the very least I would start with defining config objects of interest and their relationships if I were doing this. BTW, Prolog may make a pretty good fit for a configuration language (or a model for it) since it can compactly describe relationships. My 2 cents -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701281338.IAA11782>