On May 26, 2013, at 4:27 PM, Dirk Engling wrote:
> On 26.05.13 05:42, Teske, Devin wrote:
>
>> I chose 100% sh for bsdconfig because of a few good reasons…
>
> 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.
>
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… (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:
dte...@scribe9.vicor.com share $ pwd
/home/dteske/src/freebsd_svn/base/head/usr.sbin/bsdconfig/share
dte...@scribe9.vicor.com share $ grep '^# f_' struct.subr
# 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…
dte...@scribe9.vicor.com share $ grep '^# f_' device.subr
# 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]]
# 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 write
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.
>
I don't see your angle as perpendicular to my own… but rather that I would
like to seek to define in concrete terms what that means.
Working backwards from your list…
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-entry
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 system-
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 much
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 with
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 systems.
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 grand-
mothers and everybody in-between (that's the modular part… if you don't
like the way something works… 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.
>
You'll get no complaints from me here.
The installer is (in my view) not only where we need to provide the most helpful
functionality, but the best place to stash real developer insight when it comes
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.
>
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.
>
Well… 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.
>
Not aware of one. What would it talk about?
--
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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
