From owner-freebsd-hackers@FreeBSD.ORG Sun May 26 03:43:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85417AA6; Sun, 26 May 2013 03:43:08 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 526BF87F; Sun, 26 May 2013 03:43:07 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r4Q3gxVo016440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 22:42:59 -0500 Received: from LTCFISWMSGMB26.FNFIS.com ([10.132.99.18]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sat, 25 May 2013 22:42:59 -0500 From: "Teske, Devin" To: Dirk Engling Subject: Re: FreeBSD installers and future direction Thread-Topic: FreeBSD installers and future direction Thread-Index: AQHOWV60z6k72swSkkmGANUzy/EMLJkWZ1wAgAAkfQCAAE6UgIAAH7eAgAAtKgA= Date: Sun, 26 May 2013 03:42:58 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F5B2E7@ltcfiswmsgmb26> References: <51A0DC3F.9030301@cran.org.uk> <51A1025A.2020607@cran.org.uk> <51A14445.4060305@freebsd.org> <51A15EDF.6050600@erdgeist.org> In-Reply-To: <51A15EDF.6050600@erdgeist.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5DBEBE4CE4BA274A955546731DBE4B7C@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-25_07:2013-05-24,2013-05-25,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 03:43:08 -0000 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.