[GSOC 2008] update: install-tool

["Zach Wegner" <zwegner%gmail.com@localhost>]

Hello everyone,

I'm back with the status report. :) I've been hard at work over here
on good old sysinst, hacking it up quite a bit. Here's some context if
you need it:
http://mail-index.netbsd.org/tech-install/2008/04/25/msg000008.html
http://mail-index.netbsd.org/tech-install/2008/05/29/msg000025.html
http://netbsd-soc.sourceforge.net/projects/install-tool/
Here's a basic rundown since the last tech-install status report.

To start off, the original timeline was pretty much abandoned from the
start. In hindsight, it was a rather naive timeline, which didn't
really grasp how the project should be tackled. So I started off with
the parser on advice from my mentor. I might have spent too much time
on it initially without knowing enough about the sysinst internals,
but working on it gave me a lot of insight on the overall design. So
maybe I wasn't as aware at how sysinst worked, but it gave me more of
a chance to think about how it _should_ work.

The parser has been a very interesting project. The first impression I
get is that it's big--over 2500 lines at the moment, and it's going to
need to grow a little more, though almost all functionality is there.
It's the first lex/yacc program I've made, but I found it rather easy
to get the hang of, it was a piece of cake to write the rules and
such. But when it came to writing the code to read it into data
structures, things got more complicated. Basically I had to make the
most fine-grained details of the file into their own data structures,
as the enclosing structure is not known when it's parsed. So as an
example of what this entails, BSD partitions internally go up to 10
levels deep in structs, though this includes some SLIST_HEAD structs,
not directly used. Not too pretty as an API. This was made more
apparent by the work in the back end. So the structures used to parse
in yacc are converted into something much more programmer-friendly,
and similar to what the old sysinst used internally.

Then comes the back end. It's mostly small changes needed, and a lot
of deleting, but there have been some important design decisions made.
Simply enough, the new sysinst will be much different. There isn't the
same sort of error handling as before. The network stuff is
complicated. My thoughts are to either have the front end be able to
call the back end in test mode, i.e. it sets up the data, then the
back end sees if it would be able to install, but not actually
install, or, whenever the back end has an error, it calls up the front
end and lets the user try to fix the problems. While both are similar
in functionally, the main thing I want to avoid is duplicating code
between them. Another issue, in the same vein, is floppy disk
handling. Yes, you can still install from floppies. Right now, the
user is prompted in sequence for each part of a set, e.g. games.tgz.a.
3 hours and a hundred floppies late, it cats all of them together to
get the distribution sets. The problem is that this is a very involved
process. The idea of this project is for the entire install to be done
without user intervention, and changing floppies is about the worst
form of such. While it is possible to keep the menu system in the back
end for just this one part, my thoughts are that it might be better to
just quit supporting installation from floppies. I'd estimate the back
end and parser together should take about a little more than a week to
finish, though debugging might take longer. A full debug mode will be
implemented to describe the installation without actually performing
it. This step will also come in handy when the front and back end are
integrated, as the back end will need to be able to verify data
structures without modifying anything.

I haven't gotten to the front end yet, but I have a lot of ideas for
it. Some of these are outside the scope of the project, i.e.
unnecessary, but I'd like to work on them, and continue after the
project period. There is a lot of flexibility involved in the
configuration file format, and it will take a much different user
interface to harness this power. Initially, the front end will work
identically as it did before, and the extra functionality will be
available only by hand-editing the file. Eventually though, I'd like
to move to an "asynchronous" approach, where the front end gives a
list of steps that need to be taken for an installation, and rather
than guiding the user through them step by step, the user is free to
complete each step as they wish, fill in as much information as they
want, run the back end to test it, write out a configuration file, do
the full install, etc. All of this information can be initialized with
a preexisting sysinst.conf as well.

All in all, this has been a very interesting project for me. I have
learned a lot, about specific technologies, the design of a
substantially sized and complicated production program, and the way
large open source projects work. It is intriguing to me to get a taste
of the NetBSD community, and I hope to continue the relationship for
time to come.