From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 20:40:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0B5616A4CE for ; Wed, 21 Jul 2004 20:40:15 +0000 (GMT) Received: from cruzio.com (dsl3-63-249-85-132.cruzio.com [63.249.85.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43A5543D1F for ; Wed, 21 Jul 2004 20:40:15 +0000 (GMT) (envelope-from brucem@mail.cruzio.com) Received: from mail.cruzio.com (localhost [127.0.0.1]) by cruzio.com (8.12.10/8.12.10) with ESMTP id i6LKf5au001765 for ; Wed, 21 Jul 2004 13:41:06 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.12.10/8.12.10/Submit) id i6LKf5MO001764 for freebsd-hackers@freebsd.org; Wed, 21 Jul 2004 13:41:05 -0700 (PDT) (envelope-from brucem) Date: Wed, 21 Jul 2004 13:41:05 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200407212041.i6LKf5MO001764@mail.cruzio.com> To: freebsd-hackers@freebsd.org Subject: Re: "Next Generation" kernel configuration? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 20:40:16 -0000 Hi, re, "Next Generation" kernel configuration: Years ago I had a job for a few years where I constantly built RSX-11 systems on PDP-11s. RSX-11 was always built from source and had a couple of hundred build-time options, many hardware build dependencies, and supported numerous other dynamic build-time functions; it was said that it was possible that no 2 RSX systems were really the same binaries. It may have been more combinatorially complex than FreeBSD. An RSX build could easily take a day. Although at the core the build was driven by a file of assembly macro defines, conceptually not unlike FreeBSD, the build process went through continuous evolution over the life of RSX. A comprehensive "sysgen.bat" script, or somesuch, evolved. Sysgen (which was a common industry term at the time) was a very large script that was intended to be run on a fast hard-copy decwriter; it printed out lists of possibilities and then asked you a question, you made a selection from the options, and so on. It conducted a 'scripted dialog' that reflected the options you made along the way. You wanted this on hard copy so you could go back and check things, keep it for next time, and so on. You could go back in the dialog and repeat a section, save the sysgen state and restart later, and so on. A sysgen dialog could easily take half-a-day (sometimes intermediate things had to be built and such), and then the build itself and install could take a number of hours... At the end of the sysgen dialog you could "save the session", basically, and then the next time you did a session you could ask to use the saved session and essentially conduct a "modification dialog". Working with sysgen often felt like taking part in an adventure game with an AI opponent; you had to know how to outsmart the script to get it to do exactly what you wanted. This might be a common failing of many pseudo AI type programs. On the one had this all worked and worked well. On the other hand if you can do it by simply editing flat files it's much better, because you don't have to become an expert on the sysgen script just to do a build. Back on the other hand, there may be a point of complexity (and lack of corresponding widespread sophistication) where a sysgen program is necessary. SO: If a sysgen-like program was built for FreeBSD that used a conversational, graphic, menu, or whatever interface, instead of actually doing anything to real files or the real system, could it just print out _what to do_, that is, it would output a list of instructions - in such-and-such a file, edit this option, then add this line... Or perhaps it would output diffs to files... or put the output in a "candidate" location. But in any case the program would be a SYSGEN ASSISTANT, not an actual sysgen program. Basically a "kernel config checker", a smart build-lint, etc.. It could live in ports. If this program got to where it really worked, everyone liked the interface, and the system complexity was clearly at the point where it was needed, it could be used to directly generate system configurations. The dependency-rule evaluation and output part could be built independent of any user-interface, so a front-end back-end scheme might make sense. In any case, googling on "RSX sysgen" might produce some ideas of interest. BTW, I'm under the impression that for quite some time the largest rule-based AI application ("real-time expert system") in the world was the OPS5 system implemented at DEC to configure VAX hardware, see links such as: http://encyclopedia.thefreedictionary.com/OPS5%20rule%20based It looks like there's a public domain system that compiles rules to C code, perhaps there are some interesting ideas there as well for things like general dependency rule evaluation in the backend and such: http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/systems/ops5/0.html Sorry to go on at length. - bruce