Date: Mon, 27 May 2013 01:54:24 +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: <13CA24D6AB415D428143D44749F57D7201F61FE0@ltcfiswmsgmb21> In-Reply-To: <51A29A5F.7010106@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> <13CA24D6AB415D428143D44749F57D7201F5B2E7@ltcfiswmsgmb26> <51A29A5F.7010106@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 26, 2013, at 4:27 PM, Dirk Engling wrote:
> On 26.05.13 05:42, Teske, Devin wrote:
>=20
>> I chose 100% sh for bsdconfig because of a few good reasons=85
>=20
> First, the partedit tool makes heavy use of libgeom and the structs
> returned from that lib, so I've rather wondered why for some parts C was
> preferred, and not the other way around.
>=20
I tend to be of the mind that shell (gpart in this case) would be a better
choice for the installer than tapping into geom=85 (for the following)
Using gpart makes you exercise both the end-user utilities and the
developer framework (by-way of those utilities) whereas if you stick
to just the developer framework (libgeom in this case) there's a chance
that the installer can do things that can't be done from the command-line.
Just a thought.
If structs are what you want, I have those in bsdconfig:
dteske@scribe9.vicor.com share $ pwd
/home/dteske/src/freebsd_svn/base/head/usr.sbin/bsdconfig/share
dteske@scribe9.vicor.com share $ grep '^# f_' struct.subr=20
# f_struct_define $type $member_name1 ...
# f_struct_new $type $name
# f_struct $name
# f_struct $name get $property [$var_to_set]
# f_struct $name set $property $new_value
# f_struct $name unset $property
# f_struct_free $name
# f_struct_copy $from_name $to_name
Naturally, because it's shell, the struct members are loosely typed (so
no need to define their type).
So I think there's great potential to write a very clean "gpart.subr" that
combines the power of the above "struct.subr" with perhaps another
of my modules=85
dteske@scribe9.vicor.com share $ grep '^# f_' device.subr=20
# f_device_try $name [$i [$var_path]]
# f_device_register $name $desc $devname $type $enabled $init_function \
# f_device_reset
# f_device_get_all
# f_device_name_get $type $name type|desc|max [$var_to_set]
# f_device_name_set $type $name $desc [$max]
# f_device_desc $device_name $device_type [$var_to_set]
# f_device_rescan
# f_device_find $name [$type [$var_to_set]]=20
# f_device_init $name
# f_device_get $name $file [$probe]
# f_device_shutdown $name
# f_device_menu $title $prompt $hline $device_type [$helpfile]
NOTE: device.subr already uses struct.subr. For example, $device_type
is actually a struct type, and when you call f_device_get_all() it creates a
series of structs named "device_{name}" (where {name} is something
like "da0") and the struct holds many properties for the device.
I don't think there's any reason why we have to write it in C if we can wri=
te
it in sh.
> Still, thanks for pointing all that out, but I rather wanted to look at
> the installer from another angle, as it is supposed to provide everyone
> from FreeBSD novices to experts with a comfortable way to do things the
> right way and yet be flexible enough to avoid abandoning the tool once
> the requirements differ.
>=20
I don't see your angle as perpendicular to my own=85 but rather that I would
like to seek to define in concrete terms what that means.
Working backwards from your list=85
Flexibility: I think using a conflated shell namespace (where the entire
installer is sh and is in-turn scriptable by sh) gives the most flexibility=
. Much
more than flexibility, I think this approach also lowers the barrier-to-ent=
ry for
integration and automation engineers. Open questions: was the fact that
sysinstall was all C with a few forks to external programs a barrier to sys=
tem-
integration and system-automation engineers trying to automate the install-
and-configure process? Maybe. The BSD-P certification exam requires you
to script sysinstall in FreeBSD-8. If we go all-shell, this would become mu=
ch
easier IMHO.
Novices to Experts: I'd like to strive to hit a full spectrum between those=
two
points. I recognize that these are not two discrete ends of a dichotomous
tree, but instead a journey that is traversed (assuming the novice stays wi=
th
FreeBSD after trying it out). There are no defined sets of travel along this
line either, some people skip being a novice when they come to FreeBSD
for the first time because they have experience with similar operating syst=
ems.
That's why I've taken to developing every aspect of the utility. I want to =
see
the installer and configurator helpful to all people from developers to gra=
nd-
mothers and everybody in-between (that's the modular part=85 if you don't
like the way something works=85 the sh(1) nature allows you to simply
override it with your own module).
> So I wonder if there has ever been a best practices document on how to
> "properly" set up zpools, when to advice the user against using zfs at
> all, whether it makes sense to use geli on the boot device, when it is
> better to have multiple zpools and only encrypt the data pool(s). Maybe
> the installer should be advocating concepts like manageBE, pre-setting
> noexec-flags on /var, setting some default quotas.
>=20
You'll get no complaints from me here.
The installer is (in my view) not only where we need to provide the most he=
lpful
functionality, but the best place to stash real developer insight when it c=
omes to
analyzing the installation environment and providing "canned" recipes.
> The second part, of course, is to find visual concepts on how the user
> is guided through the default and expert bsdinstall/bsdconfig screens to
> cover the most common scenarios and still offer enough options.
>=20
I think there's two approaches to solving the issue of custom screens that =
are
not producible with normal dialog(1) or Xdialog(1) (the two interfaces that=
are
currently supported by bsdconfig; bsdinstall currently only supports dialog=
(1)):
1. Use libdialog to produce variations that dialog(1) cannot produce.
NOTE: This is what bsdinstall does.
2. Write a helper utility like ssh-askpass to be called from the shell code
The latter can take more patience, but has (imho) greater potential for re-=
use.
> All this doesn't need a developer but a bunch of veteran FreeBSD admins,
> a wiki and a lot of bike sheds to paint.
>=20
Well=85 a developer doesn't hurt. Someone to make sure the code is clean
and re-usable.
> If there's no such document yet, I propose editing one in the wiki.
>=20
Not aware of one. What would it talk about?
--=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?13CA24D6AB415D428143D44749F57D7201F61FE0>