Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!news.mathworks.com!newsxfer.itd.umich.edu!agate!reason.cdrom.com!usenet
From: "Jordan K. Hubbard" <jkh@FreeBSD.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Looking for helpers for "new sysinstall" - setup
Date: 18 Sep 1995 13:33:52 GMT
Organization: Walnut Creek CDROM
Lines: 180
Message-ID: <43jsg1$8ut@reason.cdrom.com>
NNTP-Posting-Host: time.cdrom.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.1N (X11; I; FreeBSD 2.1-STABLE i386)
X-URL: news:comp.unix.bsd.freebsd.misc
First, before I even start in here, let me just clarify that "the new
sysinstall" is not actually the working title of what I'm trying to
create here. I just used that phrase to set the context of what it is
we're talking about, which is a general installation and setup tool.
The new utility to take sysinstall's place will, in fact, be called
"setup" and I'll refer to it by that name in the rest of this message.
Second, it should be understood that I'm going out on a limb a bit
here by even talking about this. There are some, erm, contraversal
aspects to the approach I've taken with setup and in some ways I would
be far better off just finishing it in a corner and springing it on
all of you at the last minute, after it's too late to complain.. :-)
However, I also think that our history of having one or two people
working on the installation in a corner someplace has actually cost us
a fair bit in terms of user input and the kind of cooperative strategy
that FreeBSD enjoys in most other parts of its development, so I'm
going to take a chance here and see if we can't do the next generation
installer as a more cooperative effort. Please try not to give me
cause to regret this decision! :-)
Finally (long preamble, this!), it should also be made clear that this
is not a 2.1 item. This is a 2.2 project. I had some fond hopes of
getting this into 2.1, but it's now looking like it's just going to
take more time than we have to *really* do it right, and doing it
wrong in the name of expediency is exactly what we've done all along
and necessitated all these re-writes in the first place! I would like
to take some time to develop this new framework properly so that it
can really, truly be the last installation tool I write for some time
to come (oh please oh please :-). I have made enough improvements to
"the old sysinstall" that I think the 2.1 users will be happy enough
with it until we can finish this one.
OK, now on to the meat!
The first and most striking aspect of setup is that it's no longer a
monolithic installation tool but rather a "nucleus" of sorts for
creating installations. Setup has no hard-wired knowledge of a given
FreeBSD distribution or even what components make up a distribution -
all that information is external to the program.
The second aspect of setup, and an outgrowth of the need for such an
installation nucleus, is that it has an interpreted language imbeded
in it for describing such interactions, behaviors, etc. This language
is (and here comes the contraversy) forth. Why forth? Well, several
important reasons:
1. It's small. The entire forth interpreter I'm using fits
in 40K. For something we'll be sticking on a boot floppy,
especially given that we're limited to static linking only,
this is *crucial*. Yes, I'm a big fan of TCL too and have
used it in a number of commercial applications, but we're
talking *280K* for the simplest TCL based app vs 40K for the
forth engine. On a boot floppy, an extra 240K is like the
difference between life and death.
2. It's easy (in this interpreter, anyway) to hook new C calls in.
Forth has no innate types of its own to get in the way, whereas
TCL demands that anything passing through "TCL space" be coerced
to a string, and that means that you either do really gross things
to represent pointer types as strings and convert back and forth
or that you indirect everything through a hash table. This is one
of TCL's least happy features. With forth, I can cram an entire
untranslated C struct onto the stack (or somewhere in memory)
if I like and as long as the forth words know what to expect, it
just works.
3. It's light-weight. I didn't need an all-singing, all-dancing
object oriented environment for setup, I just needed some way
of being able to say "go run whatever's in that file over there"
so that I could decouple installation mechanism from installation
policy.
So whether or not you're a fan of forth, and I personally feel that
the language has been unfairly maligned in the past by those who
missed the fundamental point about what sorts of things it was
actually applicable to, that's the language that setup uses and I'm
not very likely to change my mind about this. TCL and PERL are just
too big, and I see no reason to reinvent the wheel when a perfectly
good public domain forth interpreter was available from John Walker,
the inventor of AutoCAD. It works very well indeed!
Anyway, moving right along, the fundamental approach of setup is to
provide a whole set of useful primitives for scribbing on MBRs,
doing file I/O, opening FTP connections (which are abstracted as
ordinary files - no fussing about there), putting up dialogs, drawing
on the screen with curses, doing complex string and associative array
handling, and so on. All the decisions as to how a release is put
together, that is how to extract bits of it and what sorts of
questions to ask the user, are left to the "external" portions of
setup.
In typical usage, I would see setup coming up off a floppy and looking
into the MFS area for an initialization file. This would be read in
and would be responsible for "bootstrapping" the system. Depending on
the media type chosen (a media selection menu would be one of the very
first options the user was presented with), setup would then transfer
control to a media-specific installation script. On the CDROM, this
could be a fairly CD-centric installation that knew where to find
everything and wouldn't have to ask the user many questions about
that. For an FTP install, the top level installation routines could
even *change* as we perfected the release and otherwise updated it.
The top level menu of the FTP install would probably be something to
the effect of "which release do you want to load? Here are the ones
available at this site." Depending on the release chosen, yet another
file would be invoked for presenting menus relevant to that release.
It wouldn't even matter if the user had a 6 month old boot floppy -
only the external files need to change (though I have made version and
revision information available so that the scripts can conditionalize
on features we may add to the setup progrm later).
I think people can sort of see where I'm going with all this.. :-)
Anyway, what I've implemented so far are:
o String and file handling functions.
o Most of the interesting system calls.
o ftp login/get/put/chdir and get/put by URL.
o hash tables (for associative arrays)
o dialog functions
o curses functions
o A small debugger (for debugging forth code)
o extensions for structs / case / breakpoints / etc.
o higher level I/O functions like printf/fprintf/puts/gets/etc.
o A simplistic "library" mechanism for adding C functions
to the core interpreter in a reasonably clean and segregated
fashion.
What I still need to implement:
o devconf / sysctl interface
o string/button/etc objects in libdialog (I have all the menus
and popup requestors, but none of the advanced stuff used in
apps like pkg_manage).
o A "dd" primitive for copying filehandles.
o Access to all the mount primitives
o Access to the libdisk primitives
o Access to fstab parsing primitives
o access to ifconfig primitives
o fork/exec/wait
And I'm sure there's more, but I've only been working on this for
about 2 weeks and could use some feedback and/or help.
I feel very strongly that this is the only approach that will finally
get us past the limitations inherent in doing installations as
monolithic C programs that cannot be easily extended and I'm very
eager to see just where we can go with this.. If the chosen
interpreter bothers you then don't think of it as forth, think of it
as a very very powerful macro language! :-)
A very early snapshot of my work is now on:
ftp://freefall.freebsd.org/incoming/setup.tar.gz
I would like to emphasise that this is probably only of interest to
those who are genuinely interested in working with me on setup since
this is very early days code here. It implements the primitives I
described earlier and does represent the overall direction I'd like to
go in, but it's still a very skeletal framework. In some ways that's
good, since those of you who really would like to be a part of making
setup into the coolest installation and management utility ever for
UNIX at least have a chance to get in on the ground floor.. :-)
Feedback more than welcome! Genuine offers of assistence even more
so! I'm really very happy to work with anyone genuinely motivated to
get involved with this and will do whatever I can to explain the
overall framework, how to add C primitives, etc. but please, don't
pipe up unless you're really interested in going the distance with
this! Explaining any work-in-progress takes serious time and time is
something I'm very short on right now. A genuine "investment" in
bringing someone up to speed I'm more than happy to make, but if
people just pelt me with questions and then go away again it will only
impede progress and send me off in a corner again, muttering bitterly
to myself about people who waste my time.. :)
Thanks!
--
Jordan