Date: Tue, 28 May 2013 19:16:27 -0400 From: Super Bisquit <superbisquit@gmail.com> To: Devin Teske <dteske@freebsd.org> Cc: Bruce Cran <bruce@cran.org.uk>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Alfred Perlstein <bright@mu.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: FreeBSD installers and future direction Message-ID: <CA%2BWntOuM7kLAofYkPuOwwf1On=MpQaoOxQL84LRq69XcjyFwog@mail.gmail.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201F6484E@ltcfiswmsgmb21> 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> <13CA24D6AB415D428143D44749F57D7201F6484E@ltcfiswmsgmb21>
next in thread | previous in thread | raw e-mail | index | archive | help
In the case of firmware loaded systems, all of them aren't going to work with a single boot loader. On Tue, May 28, 2013 at 1:15 PM, Teske, Devin <Devin.Teske@fisglobal.com>wr= ote: > > 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 > single UI and scripting interface across all platforms. We should try and > get pc-sysinstall running on all of them first in case there's some probl= em > that means it can't be done, in which case we'd need to use a different > backend. > > > There are just going to be certain platforms that make it EASY to do cool > things. We should embrace that! That's why there are different platform= s! > > 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, i= f > it is very difficult, or just never happening, then we can't limit > everyone's experience based on the more difficult and/or resource strappe= d > platforms. > > It's just not good business. > > Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup > support, 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 > installer 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 undertaking given its enormous flexibility. The bsdinstall > partition editor has been written to be extensible for this, and several > people have started writing code to do it, but no one ended up having tim= e > to finish. Probably a reasonable thing to do is to start with supporting > only a minimal set of features. If anyone felt like actually writing this > code, I'm sure it would be 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 > is here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are > IPv6 (maybe this has changed?) and no jail setup feature. Most of the > existing disk partitioning code in pc-sysinstall, which is the only thing > in a FreeBSD installer that is at all complicated, is also *extremely* > fragile and needs in all likelihood to be entirely replaced. The merge > effort stalled because of this kind of issue -- doing a "merge" rapidly > became rewriting both 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 th= e > 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 > these issues to be secondary to the above-stated larger issues. > > Concretely, I'm saying thus: > > + bsdinstall lacks debugging (debugging is different than logging; from > what I could see BSDINSTALL_LOG -- although utilized by both the sh(1) si= de > and the C side -- is only populated during an installation). The ability = to > have the type of debugging that is in bsdconfig would greatly diminish th= e > amount of time developing important new features. > > + pc-sysinstall lacks debugging (similar situation=85 producing a log for > some action is not the same as being able to have debug statements for th= e > purpose of enhancement the program or troubleshooting an enhancement) > > + bsdinstall separates the backend functionality and the front-end > functionality 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 > dialog screens > > or > > bsdconfig -D fooLogfile > # produce debugging statements in "fooLogfile" (debugging statements are > hidden from stdout) > > or > > bsdconfig -D +fooLogfile > # produce debugging statements in both "fooLogfile" *and* on stdout (this > is 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 by 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 > comparison). > > In bsdinstall, we see namespace separation most readily by looking at the > way 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 the 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 > bsdinstall=85 that's going to be difficult (but not impossible=85 you cou= ld > 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 above manner is still non-trivial). > > On the other-hand=85 pc-sysinstall doesn't suffer from the same namespace > problems (it's 100% shell), but it's still not conflated as-is done in > bsdconfig. > > In pc-sysinstall what you'll find is that instead of putting functionalit= y > into actual functions=85 it creates shell scripts that operate in a separ= ate > 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 > should perhaps embrace the ability to avoid forking all the time and run > everything in a conflated [single] namespace). > > =3D=3D=3D > > And as Nathan points out=85 it quickly starts to look like a rewrite of b= oth > to do a merge. > > However=85 the type of "merge" that was being talked about in the above U= RL > (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 > where 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, > because pc-sysinstall expects you to treat the largest portions of its > functionality as black-box executables (e.g. you call "delete-part.sh" wi= th > arguments=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 > (bsdinstall being the newer entity on the block=85 so it has more up-to-d= ate > coding style, albeit not the latest; contrasted to pc-sysinstall's dated > inconsistencies within its own code-base -- so a merge in the opposite > direction, 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 o= f > too many namespaces and the equally-distression problem of not having a > debug layer (which is only marginally helpful if you have a fractured > namespace 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 > the 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 (bsdconfi= g) > where the third entity has much more freedom to play. > > The end result would be that, when bsdconfig does indeed incorporate all > the migrated functionality (and rewritten to achieve the desired > enhancements to make development and maintenance easier), we then -- and > only then -- disrupt things by wholly replacing them. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete t= he > message and all copies; (ii) do not disclose, distribute or use the messa= ge > in any manner; and (iii) notify the sender immediately. In addition, plea= se > 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-unsubscribe@freebsd.org= " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BWntOuM7kLAofYkPuOwwf1On=MpQaoOxQL84LRq69XcjyFwog>