From owner-freebsd-hackers@FreeBSD.ORG Tue May 28 23:56:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80F197DD; Tue, 28 May 2013 23:56:06 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4E361E; Tue, 28 May 2013 23:56:05 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r4SNtwmS026812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 May 2013 18:55:58 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Tue, 28 May 2013 18:55:59 -0500 From: "Teske, Devin" To: Super Bisquit Subject: Re: FreeBSD installers and future direction Thread-Topic: FreeBSD installers and future direction Thread-Index: AQHOWV60z6k72swSkkmGANUzy/EMLJkWZ1wAgAAkfQCAAE6UgIAAH7eAgAAeuACAAA8cgIACXGSAgAAS94CAABK3AIAACk6AgAAeVACAAA8kAIAAR84AgAAD5oCAAC1WgIAAq02AgAASJICAABbCAIAAZMiAgAALCoA= Date: Tue, 28 May 2013 23:55:58 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F65269@ltcfiswmsgmb21> References: <51A0DC3F.9030301@cran.org.uk> <51A1025A.2020607@cran.org.uk> <51A14445.4060305@freebsd.org> <51A15EDF.6050600@erdgeist.org> <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-28_10:2013-05-28,2013-05-28,1970-01-01 signatures=0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Bruce Cran , FreeBSD Hackers , Devin Teske , Alfred Perlstein , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:56:06 -0000 On May 28, 2013, at 4:16 PM, Super Bisquit wrote: In the case of firmware loaded systems, all of them aren't going to work wi= th a single boot loader. Uh=85 On the surface, what you're talking about seems to be unrelated to the disc= ussion at-hand. Nobody said anything about unifying the boot loader. We're talking about the installer=85 not the boot loader. *usually* the installer doesn't care about how it got to its installation e= nvironment. NOTE: I say *usually* because there *are* specialized situations like cobbl= er + mfsbsd + pc-sysinstall in which case the boot loader needs to provide = certain information (which is then accessible through kenv(1)). That type o= f installation setup will fail if the specialized boot loader does not boot= on the desired target installation platform *or* the boot loader that _doe= s_ work on said platform doesn't provide the necessary information. That being said=85 bsdinstall doesn't require special knowledge from the bo= ot loader (to the best of my knowledge). sysinstall didn't need special info from the boot loader either. I don't see why talking about a unified installer has to include a discussi= on involving unifying the boot loader (a topic in my mind that is unattaina= ble). -- Devin On Tue, May 28, 2013 at 1:15 PM, Teske, Devin > wrote: 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 = IPv6 (maybe this has changed?) and no jail setup feature. Most of the exist= ing disk partitioning code in pc-sysinstall, which is the only thing in a F= reeBSD installer that is at all complicated, is also *extremely* fragile an= d 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 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. _______________________________________________ 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" _____________ 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.