"Next Generation" kernel configuration?

Thu Jul 22 17:33:54 PDT 2004

Mmmm... I had something similar (much smaller) supplied with
my Cromemco Z-80 CROMIX system... early 80's for the historical.

You were prompted through a series of questions re the desired
requirements for i/o devices etc. and then the last step would rebuild
the 'kernel' to that configuration.

It wasn't actually doing a full build as all the supplied stuff came out
of linkable libraries, BUT one could use an assembler 'template' to
create ones own device drivers for the homebrewed 'MummbleFrotz' device.

These 'user-created drivers' were then assembled, loaded into your own
library and became a linkable element from then onwards that you could
add during any subsequent 'kernel rebuilds'

If I remember correctly- the main elements of the template were
- an entry 'jump table' for such things as Initialise (ENTRY+0), 
	Open (ENTRY+2), Read (ENTRY+4) ....  
- a place to define major:minor numbers and the rules / options
	pertaining thereto, 
- and finally how to return data and driver status.  

Fun.
mjt

On Thu, 2004-07-22 at 06:41, Bruce R. Montague wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 
> ****************************************************************
> This Email has been scanned for Viruses by MailMarshal.
> ****************************************************************
-- 
Murray Taylor
Special Projects Engineer
---------------------------------
Bytecraft Systems & Entertainment
P: +61 3 8710 2555
F: +61 3 8710 2599
D: +61 3 9238 4275
M: +61 417 319 256
E: murraytaylor at bytecraftsystems.com
or visit us on the web
http://www.bytecraftsystems.com
http://www.bytecraftentertainment.com

---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material. 

E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------

****************************************************************
This Email has been scanned for Viruses by MailMarshal.
****************************************************************