Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 May 2013 17:15:45 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Bruce Cran <bruce@cran.org.uk>, 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:  <13CA24D6AB415D428143D44749F57D7201F6484E@ltcfiswmsgmb21>
In-Reply-To: <51A4D329.5060103@mu.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> <CA%2BWntOtrgkstTOamTZh9_FvATd8a55ca9hCUFF1sE=2zSd4EQA@mail.gmail.com> <13CA24D6AB415D428143D44749F57D7201F5B337@ltcfiswmsgmb26> <51A38051.8040909@mu.org> <51A39039.1070202@cran.org.uk> <51A39FEC.5070402@mu.org> <51A3A891.5060103@cran.org.uk> <51A3C202.9030802@mu.org> <51A3CEB6.3070200@cran.org.uk> <51A40AF2.2010108@mu.org> <51A40E37.9060702@freebsd.org> <51A4343F.3070605@mu.org> <51A4C3F1.2010604@freebsd.org> <51A4D329.5060103@mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On May 28, 2013, at 8:54 AM, Alfred Perlstein wrote:

On 5/28/13 7:49 AM, Nathan Whitehorn wrote:
On 05/27/13 23:36, Alfred Perlstein wrote:
On 5/27/13 6:53 PM, Nathan Whitehorn wrote:
On 05/27/13 20:40, Alfred Perlstein wrote:
On 5/27/13 2:23 PM, Bruce Cran wrote:
On 27/05/2013 21:28, Alfred Perlstein wrote:
On 5/27/13 11:40 AM, Bruce Cran wrote:
Yes.
Is this a joke?

It probably /was/ too short a reply. Personally I think there should be a s=
ingle UI and scripting interface across all platforms. We should try and ge=
t pc-sysinstall running on all of them first in case there's some problem t=
hat means it can't be done, in which case we'd need to use a different back=
end.


There are just going to be certain platforms that make it EASY to do cool t=
hings.  We should embrace that!  That's why there are different platforms!

Some are great for low power, others are great for graphics, cpu power, gpu=
, networking etc.

If we always go for the lowest common denominator then we are crippling all=
 the platforms for no one's benefit.  Even if something CAN be done, if it =
is very difficult, or just never happening, then we can't limit everyone's =
experience based on the more difficult and/or resource strapped platforms.

It's just not good business.

Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup su=
pport, for instance. Right now we support what we support because it is the=
 most feature-complete thing we have, not just on tier-2 platforms but also=
 on x86.

To bring this discussion back to the ground, the fact is that we lack an in=
staller that has both internal support for ZFS and a UI. One of the reasons=
 for this is that making a good expressive UI for ZFS is a non-trivial unde=
rtaking given its enormous flexibility. The bsdinstall partition editor has=
 been written to be extensible for this, and several people have started wr=
iting code to do it, but no one ended up having time to finish. Probably a =
reasonable thing to do is to start with supporting only a minimal set of fe=
atures. If anyone felt like actually writing this code, I'm sure it would b=
e appreciated by all and be more productive than email exchanges.
-Nathan

I'm sure if there was a list of reasonable things, such as wireless then pc=
-sysinstall could be augmented.  This is the first I've heard of that.  All=
 the other complaints have been based on portability.

Is that all that is required now, wireless?

There are more, as well. A partial list of missing features on both sides i=
s here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are IP=
v6 (maybe this has changed?) and no jail setup feature. Most of the existin=
g disk partitioning code in pc-sysinstall, which is the only thing in a Fre=
eBSD installer that is at all complicated, is also *extremely* fragile and =
needs in all likelihood to be entirely replaced. The merge effort stalled b=
ecause of this kind of issue -- doing a "merge" rapidly became rewriting bo=
th from scratch.
-Nathan

Ah this is so cool.  I'll bring it up with the PCBSD folks today.

Thank you Nathan.


I had my own look at the pc-sysinstall and bsdinstall code and came to the =
same conclusions, plus some.

One of the biggest obstacles I see is actually a high-level issue that I've=
 self-identified through extensive work on bsdconfig (which is both a back-=
end and a front-end).

This is the issue of debugging and namespaces.

I've sat down and made lists of other issues=85 but when I review, I find t=
hese issues to be secondary to the above-stated larger issues.

Concretely, I'm saying thus:

+ bsdinstall lacks debugging (debugging is different than logging; from wha=
t I could see BSDINSTALL_LOG -- although utilized by both the sh(1) side an=
d the C side -- is only populated during an installation). The ability to h=
ave the type of debugging that is in bsdconfig would greatly diminish the a=
mount of time developing important new features.

+ pc-sysinstall lacks debugging (similar situation=85 producing a log for s=
ome action is not the same as being able to have debug statements for the p=
urpose of enhancement the program or troubleshooting an enhancement)

+ bsdinstall separates the backend functionality and the front-end function=
ality into two separate namespaces (and in the case of C binaries, a third =
namespace)

+ pc-sysinstall separates one backend into more than one namespace

=3D=3D=3D

To get an idea of the type of debugging I'm talking about, install sysutils=
/bsdconfig from the ports tree or install it from a HEAD checkout of base (=
it's in usr.sbin) and execute:

bsdconfig -d
# produce debugging statements on stdout collated in realtime with the dial=
og screens

or

bsdconfig -D fooLogfile
# produce debugging statements in "fooLogfile" (debugging statements are hi=
dden from stdout)

or

bsdconfig -D +fooLogfile
# produce debugging statements in both "fooLogfile" *and* on stdout (this i=
s the same as "-dD fooLogfile")


As this stuff gets more modular and there are back-ends, front-ends, global=
 APIs, local APIs, etc. etc.

Having the ability to (after noticing a problem) flip a switch and then get=
 an almost exact location of where you currently-are within the code just b=
y looking at debug statements is extremely helpful in being able to locate =
the problem.

=3D=3D=3D

The namespace argument is a bit harder to explain (and quantify for compari=
son).

In bsdinstall, we see namespace separation most readily by looking at the w=
ay the C binaries work.

The namespace separation in this case means that (despite the fact that the=
 C components do a getenv(3) to acquire $BSDINSTALL_LOG, for example) for t=
he large part, the C aspects cannot enjoy code written to extend the sh(1) =
aspect, and vice-versa.

So if you want a nice debug library that acts in a single way for bsdinstal=
l=85 that's going to be difficult (but not impossible=85 you could perhaps =
cheat by having both the sh(1)-side and the C-side use a logger(1)/syslog(3=
) facility =85 but then getting that debug information integrated in the ab=
ove manner is still non-trivial).

On the other-hand=85 pc-sysinstall doesn't suffer from the same namespace p=
roblems (it's 100% shell), but it's still not conflated as-is done in bsdco=
nfig.

In pc-sysinstall what you'll find is that instead of putting functionality =
into actual functions=85 it creates shell scripts that operate in a separat=
e namespace as they are executed as binaries rather than taking advantage o=
f their shell-based nature (in other words=85 because it's 100% shell, it s=
hould perhaps embrace the ability to avoid forking all the time and run eve=
rything in a conflated [single] namespace).

=3D=3D=3D

And as Nathan points out=85 it quickly starts to look like a rewrite of bot=
h to do a merge.

However=85 the type of "merge" that was being talked about in the above URL=
 (reproduced below from the above reply text for convenience):

https://wiki.freebsd.org/PCBSDInstallMerge

Is not a merge that would see a single namespace emerge.

In the above URL, the type of "merge" that's being posited is the kind wher=
e bsdinstall becomes a front-end only and will call-out to everything that =
pc-sysinstall provides.

This could only be bad if pc-sysinstall is left in its current state, becau=
se pc-sysinstall expects you to treat the largest portions of its functiona=
lity as black-box executables (e.g. you call "delete-part.sh" with argument=
s=85 rather than loading a shell library with a delete-part() function).

Debugging is harder when you have to cross a namespace threshold.

Perhaps a better style of merge would be the traditional use of the word=85

That is to say, that pc-sysinstall should be slurped *into* bsdinstall (bsd=
install being the newer entity on the block=85 so it has more up-to-date co=
ding style, albeit not the latest; contrasted to pc-sysinstall's dated inco=
nsistencies within its own code-base -- so a merge in the opposite directio=
n, of giving pc-sysinstall a user interface, would be harder).

However (again, with these however statements)=85

If the idea is to merge pc-sysinstall and bsdinstall to solve the issue of =
too many namespaces and the equally-distression problem of not having a deb=
ug layer (which is only marginally helpful if you have a fractured namespac=
e design)=85

=85 I think we could do a lot better.

Perhaps not better with the out-come (which would be hard to judge before t=
he product is truly envisaged), but with respect to disruptiveness.

I recognize that any forward motion in the bsdinstall or pc-sysinstall camp=
 would be disruptive to the people dependent on those technologies.

Meanwhile, nobody is depending on bsdconfig at the moment.

A less (or perhaps, totally non-) disruptive path would be to merge the two=
 entities (bsdinstall and pc-sysinstall) into a third entity (bsdconfig) wh=
ere the third entity has much more freedom to play.

The end result would be that, when bsdconfig does indeed incorporate all th=
e migrated functionality (and rewritten to achieve the desired enhancements=
 to make development and maintenance easier), we then -- and only then -- d=
isrupt things by wholly replacing them.
--
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?13CA24D6AB415D428143D44749F57D7201F6484E>