Date: Sun, 26 May 2013 03:42:58 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Dirk Engling <erdgeist@erdgeist.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Devin Teske <dteske@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: FreeBSD installers and future direction Message-ID: <13CA24D6AB415D428143D44749F57D7201F5B2E7@ltcfiswmsgmb26> In-Reply-To: <51A15EDF.6050600@erdgeist.org> References: <51A0DC3F.9030301@cran.org.uk> <CAK6u07WDZrWU4dnrBzQGYf%2BpbmibK7KxSUZyvie8jJQ1SMODuw@mail.gmail.com> <51A1025A.2020607@cran.org.uk> <51A14445.4060305@freebsd.org> <51A15EDF.6050600@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 25, 2013, at 6:01 PM, Dirk Engling wrote: > On 26.05.13 01:07, Nathan Whitehorn wrote: >=20 >> 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 >=20 > 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. >=20 Very Cool! I do encourage you to take a peak at bsdconfig either from HEAD or from por= ts (in sysutils)=85 However, I'm getting ready to drastically change the API very soon (as prev= iously threatened). I'm in the home-stretch and I'm trying to get in all th= e 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. >=20 I tend to agree. In fact=85 the directory structure of pc-sysinstall and even the way it sto= res 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. "dia= log.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 w= ould be better if they lived in bsdconfig and got imported at runtime by bs= dinstall (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, et= c.) bsdconfig is the program designed to configure things either during install= ation time or post-installation time bsdinstall would be used on the boot media to install bare metal (but durin= g that installation, made use bsdconfig for things like configuring users, = boot services, networking, etc.). It will also be used after installation a= nd running in multi-user land to do things like install jails. So in other words=85 anytime something could conceivably be wanted by bsdco= nfig=85 we should just birth it there and have bsdinstall reach out for it.= Seems to make sense=85 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? >=20 Can't answer for Nathan (and not sure if you want my opinion), but=85 I chose 100% sh for bsdconfig because of a few good reasons=85 I ultimately wanted to (and did) make it scriptable. The scripts are actual= ly `sourced' shell scripts. So=85 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 nea= rly anything. There are no frustrating moments where a C aspect doesn't sup= port 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 current= ly=85 just that it *was* a problem with sysinstall. For example=85 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=85 if you wante= d to have a sysinstall script that (a) formatted some disks with some slice= s and (b) then formatted those slices with some BSD labels =85 well=85 you = couldn't (note: this is not to say couldn't get sysinstall to write both sl= ices 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 c= all "deviceRescan" after doing the slice action on the bare metal so that s= ysinstall would pick up the "s1" slice on which you wanted to later write l= abels on. In the case of sysinstall=85 a one-line change of adding the deviceRescan()= function to the resWord mapping in dispatch.c would have made that functio= nality 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 imag= ine in shell. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201F5B2E7>