"Next Generation" kernel configuration?

[Bruce R. Montague]

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