> #1 More use of subwindows..  Use pipes to direct input from sub processes to
> the sub-windows, to avoid screen transients.

Preferably these should become scrollback 'log windows' so that you can look
at the output of all the newfs commands like the instructions tell you to.

Someday we should audit newfs and make sure that all "normal" output goes to
stdout, and all "interesting" messages go to stderr, so sysinst can display
just one or the other, or both interlaced with different colors...

> #2 logging of all activites performed by sysinst, and the output.. This will
> make it easier for people to send detailed PR's and review what happened..
> (possibly similar to smit, a log and a script)

Right, we just have to figure out how to get this data off of a host that is
running the INSTALL kernel.  For someone who's successfully set up their
network card and can SMTP out to netbsd.org, it won't take much work. But in
other cases we may have to do something like 'tar cvf /dev/fd0a logfile'.

> #3 take a look at some post-install uses of sysinst.. such as disklabel
> twiddling and basic admin tasks.. (possibly opening the door for future use
> with packages)

Sounds good. I am hoping to get enough information about the packages to
allow accurate computation of the necessary root/var/etc/usr partition sizes.
I'm even thinking about gross hacks with vnd and mfs to create a write-only
filesystem that can only write files, tell you how many blocks they use, and
delete them. This way I can use the ffs logic itself to count the inode and
indirect block overhead for the various block/fragment sizes. This would be
selected by the "slow but accurate" option to sysinst.

Todd Whitesel
toddpw @ best.com