Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:

> On 10/09/13 01:13, Allan Jude wrote:
>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>>> On 10/07/13 21:59, Allan Jude wrote:
>>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>>> obvious bugs before we send it off to re_at_ to get it committed.
>>>> 
>>>> It includes a single configuration menu that allows you to select all of
>>>> the required details, including which drives to use (gets details from
>>>> camcontrol, also includes an inspection utility that presents the
>>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>>> ZFS RAID level to use (taking in to consideration the selected number of
>>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>> 
>>>> 
>>>> Additional, it includes some other changes to bsdinstall:
>>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
>>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>>> feature has been combined into the regular 'services to enable' dialog
>>>> and enabled by default
>>>> 
>>>> 
>>>> You can browse the patches here:
>>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>> 
>>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>>> available compressed (48 MB) or uncompressed (211 MB):
>>>> 
>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>> 
>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>> 
>>>> 
>>>> We look forward to your feedback
>>>> 
>>> Thanks for doing this! I had a few comments:
>>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>>> -m, not -p, for this.
>> I had not considered that, I'll make that change
>> 
>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>>> instead of GPT.
>> I'll disable sparc64 as well
>> 
>>> 2. Why are you using camcontrol? That is guaranteed not to work on
>>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>> The GEOM ident string doesn't do enough to help the user identify which
>> drive is which.
>> More data is not exposed anywhere that I could find
>> 
>> What we really need, is dev.ada.0.desc% like we have for network
>> interfaces and a slew of other devices. GEOM data is great, but it is
>> not exposed in a shell friendly way any place that I could find, other
>> than the sysctl with DOT and XML data.
> 
> This is one of the reasons the partition editor is written in C. There
> are a few other odd corner-cases where C is much more powerful than the
> command-line for the GEOM operations that partedit needs to do. I'm not
> sure how to usefully get it just from the shell. You can see how to do
> it in C in the boot_disk() routine of partedit/auto_part.c.
> 
>>> 3. Any plans to integrate this into the regular partition editor? ZFS
>>> support is important enough that I will definitely not get in the way,
>>> even as a bolt-on, but it would be a shame for it to stay that way. The
>>> editor is also designed for ZFS to be added.
>> I am a sysadmin, not a programmer. I can't write C. Most people
>> deploying servers can't write C. I agree with Devin Teske, if everything
>> was in shell it would be a lot more usable for non-developers, who
>> probably make up the majority of people who deploy FreeBSD.
> 
> There are some cases the other way too. Devin is probably the most
> shell-proficient FreeBSD committer.

Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself).


> I certainly can't write shell
> scripts at that level, which means that for me bsdconfig, for example,
> is effectively read-only (and quite hard to read as well).

In the past few days of working on the bsdinstall_zfs patch-set with Allan
Jude, I learned something new actually.

It seems that sh(1) doesn't suffer so much from this "read only" concept.

Imagine you're starting a new C project on an operating system that has
all new syscalls and all new APIs that you've never seen. Would be pretty
hard, no doubt. Now imagine that you're thrown a life-line called POSIX
and hey, now you're slinging code in MinGW on Windows when you don't
know a lick of M$ syscalls or APIs.

In a similar manner, I've witnessed functionality be added that is truly
functional *without* using any of the API calls. Then I come in and do
a round of optimizations to leverage the existing API.

Shell is kinda like that...

I'm noticing Allan Jude doesn't know all the API calls yet (who could? other
than me of course -- and even I have trouble remembering them _all_) yet
this doesn't phase him (or others) from jumping in and lending a hand.

No different than C, but the read-only aspect is lessened significantly I
believe because there are so many people out there that know enough
good shell syntax and are just a stone's throw away from *great* shell
syntax (which I must admit jilles helped me cross that boundary).

I think in C, the read-only aspect is greater because its harder to parcel-out
the functions for a unit-test; harder to inject new code; and harder to get
to a functioning end-state.



> I suspect the
> same is true for many other developers. Without any prejudice about the
> relative merits of the languages, this can cause some significant
> internal maintenance issues. Something similar happened to sysinstall
> (which was in C): due to its complexity and high amounts of magic, it
> had become read-only for basically all committers and as a result fell
> years and years behind the rest of the project. Hopefully this is
> paranoia, but I can easily see complex shell scripts engendering the
> same problem.
> 

I surely hope this doesn't happen to bsdconfig, and I hope the fact that the
shell API is completely optional is a huge help.

However, I've implemented the following to help demystify the API and
make it accessible in a human format (backward compatible with
sysinstall(8)'s install.cfg file -- except from within a shell script).

http://svnweb.freebsd.org/base/releng/9.2/usr.sbin/bsdconfig/share/script.subr?revision=253912&view=markup

But I didn't stop there...

I understand the importance of visual aids. So I made the "dot" module
for bsdconfig(8) which has the power to produce an SVG mapping all
of the includes, where they get used, how to get to certain modules, and
more. I'll save you the reading of "bsdconfig dot -h" (it's long) and instead
just give you a pretty picture to look at.

Here's how *I* personally keep tabs on the API:

http://druidbsd.sourceforge.net/download/bsdconfig/bsdconfig-HEAD-20130506-3c.svg

NOTE: It helps that I periodically use the instructions documented in
"bsdconfig dot -h" to produce a Human-sized poster so I can "get up-close
and personal with the API." (both literally and figuratively)

But of course, it doesn't stop there...

That graphic is generated dynamically. So as people other than me
join forces (dear God... please send help!!) the graph will grow without
any additional work.

So I've tried my darndest to do everything in my power to make the API
not read-only... make the API optional (so you can skip it and just start
coding like a mad-man if you know shell really well)...

And last but not least...

You actually don't have to use shell *at all* (that's how optional this stuff is).

Any module can be C if it wants (you'll just likely end up duplicating a lot
of code -- that's why I think the answer should be... write it in shell so you can
leverage an API that can keep your code short and succinct... and if you need
C, write a general purpose tool as a call-out utility).



> In any case, this particular comment was just related to the benefits of
> having one tool, and one UI, rather than duplicating partitioning logic
> in multiple places.

I wholly agree with minimizing code duplication. I've been taking to figuring
out which parts truly have to be (or can offer above-and-beyond value-add)
in C -- and then writing abstract general-purpose utilities to solve those issues.
(and as a bonus, if need-be, creating a library for C-level access).



> None of this is actually complicated, so the
> duplication isn't that bad, but doing everything in one place long-term
> is almost certainly better for the user, no matter what programming
> language that tool is written in.

(smiles)
-- 
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.