FreeBSD installers and future direction

[Teske, Devin]

On May 25, 2013, at 6:01 PM, Dirk Engling wrote:

> On 26.05.13 01:07, Nathan Whitehorn wrote:
> 
>> I'm not aware of any movement there (on either side of the table). I'd
>> personally be very suspicious of an all-sh(1) future -- by far the
>> cleanest parts of bsdinstall are in C -- and this is especially true for
>> interacting with geom. That said, since I've lost nearly all of my free
>> time and ability to work on bsdinstall, I won't get in the way of anyone
>> else working on things
> 
> As discussed at BSDCan, I'd be willing to participate in the development
> and at least implement setting up zpools/zfs and geli/gbde providers. I
> have done similar things in sh in my ezjail tools and think I can glue
> the rest together.
> 

Very Cool!

I do encourage you to take a peak at bsdconfig either from HEAD or from ports (in sysutils)…

However, I'm getting ready to drastically change the API very soon (as previously threatened). I'm in the home-stretch and I'm trying to get in all the API changes before broaching the idea of taking off the "WITH_BSDCONFIG" build-option requirement.


> Scanning through the pc-sysinstall code, I find nothing too fancy there
> regarding either interaction with zfs nor geom tools. I do not think it
> is necessary as a back end just for these features.
> 

I tend to agree.

In fact… the directory structure of pc-sysinstall and even the way it stores the subroutines in *.sh files means I would be compelled to restructure the thing into proper "includes".

Since I intend to rework bsdinstall to use bsdconfig's libraries (e.g. "dialog.subr"), it sounds like a really nice path would be to develop:

base/head/usr.sbin/bsdconfig/share/zfs.subr
base/head/usr.sbin/bsdconfig/share/geom/
base/head/usr.sbin/bsdconfig/share/geom/geli.subr

And then bsdinstall could include those. The reason I tell myself that it would be better if they lived in bsdconfig and got imported at runtime by bsdinstall (rather than living in bsdinstall) is that I want to move to brand the utilities in this way:

bsdinstall is the program designed to install things (bare metal, jails, etc.)
bsdconfig is the program designed to configure things either during installation time or post-installation time

bsdinstall would be used on the boot media to install bare metal (but during that installation, made use bsdconfig for things like configuring users, boot services, networking, etc.). It will also be used after installation and running in multi-user land to do things like install jails.

So in other words… anytime something could conceivably be wanted by bsdconfig… we should just birth it there and have bsdinstall reach out for it. Seems to make sense… a person installs once but configures many times.

Guess I'm saying of course, that there'd be a great use for a zfs and geli library to bsdconfig for managing zfs after booting, etc.



> Nathan, is there any design rationale available for the scripts, e.g. on
> why you chose sh versus C and were you provided with some kind of wish
> list/requirements in the first place? Any particular mail thread to scan
> through beforehand?
> 

Can't answer for Nathan (and not sure if you want my opinion), but…

I chose 100% sh for bsdconfig because of a few good reasons…

I ultimately wanted to (and did) make it scriptable. The scripts are actually `sourced' shell scripts. So…

Because bsdconfig is sh, and the script is sh, the script has access to all of the bsdconfig internals, every API call, every variable, and can do nearly anything. There are no frustrating moments where a C aspect doesn't support running in a desired mode because that particular aspect was not made configurable or tunable. Not that this was (or is) a problem at all currently… just that it *was* a problem with sysinstall. For example…

sysinstall had a deviceRescan() function but the dispatch.c system did not make *that* particular function available through the system of hard-coded resWords (reserved words) that were allowed in a script. So… if you wanted to have a sysinstall script that (a) formatted some disks with some slices and (b) then formatted those slices with some BSD labels … well… you couldn't (note: this is not to say couldn't get sysinstall to write both slices and labels, just that if you wanted to do this *OUT* of the context of a full install, you couldn't). The problem was that you really needed to call "deviceRescan" after doing the slice action on the bare metal so that sysinstall would pick up the "s1" slice on which you wanted to later write labels on.

In the case of sysinstall… a one-line change of adding the deviceRescan() function to the resWord mapping in dispatch.c would have made that functionality available to scripts.

bsdconfig doesn't have that problem because the scripts are actually shell scripts and the old sysinstall commands are replicated by shell functions. There is never any need to "map" a function before it becomes available to the scripting back-end. Any/all functions are simply available *AND* (heh, unlike sysinstall) you can pass arguments and do anything else you can imagine in shell.
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.