From owner-svn-src-all@FreeBSD.ORG Sun Oct 13 15:39:26 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E26AFD1; Sun, 13 Oct 2013 15:39:26 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1429C2869; Sun, 13 Oct 2013 15:39:25 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r9DFdGsC032595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Oct 2013 10:39:17 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sun, 13 Oct 2013 10:39:15 -0500 From: "Teske, Devin" To: Nathan Whitehorn Subject: Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts Thread-Topic: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts Thread-Index: AQHOx2PjW1uGCLtcyE2zUcTOTrV8Ig== Date: Sun, 13 Oct 2013 15:39:14 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC60628@LTCFISWMSGMB21.FNFIS.com> References: <201310112041.r9BKfZeT002056@svn.freebsd.org> <5258F9B3.7030101@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC5BB95@LTCFISWMSGMB21.FNFIS.com> 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.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <8996B5DA6EB54F46B8A5469BBA345EBD@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-13_01:2013-10-11,2013-10-13,1970-01-01 signatures=0 Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "Teske, Devin" , Nathan Whitehorn , "svn-src-head@freebsd.org" , Devin Teske X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 15:39:26 -0000 On Oct 13, 2013, at 12:41 AM, Nathan Whitehorn wrote: >=20 >=20 > On Sat, 12 Oct 2013, Teske, Devin wrote: >=20 >>=20 >> On Oct 12, 2013, at 12:26 AM, Nathan Whitehorn wrote: >>=20 >>> On 10/11/13 22:41, Devin Teske wrote: >>>> Author: dteske >>>> Date: Fri Oct 11 20:41:35 2013 >>>> New Revision: 256343 >>>> URL: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://svnweb.freebs= d.org/changeset/base/256343&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrj= s6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DLDzuPpXPP4D5BzfISZjw%2BXitYn4aKVzfXzcr= mMNFo2U%3D%0A&s=3D3d0963d9c497f7bad0918888032ca62844580612dc48ab3a8a6768fe6= 40c365b >>>>=20 >>>> Log: >>>> Add zfsboot module as an option for automatic configuration. Default is >>>> to run interactively but it can be scripted too (optinally completely >>>> non-interactive). Currently supports GELI and all ZFS vdev types. Also >>>> performs validation on selections/settings providing error messages if >>>> necessary, explaining (in plain language) what the issue is. Currently >>>> the auto partitioning of naked disks only supports GPT and MBR (VTOC8 >>>> pending for sparc64), so is only available for i386/amd64 install. >>>>=20 >>>> Submitted by: Allan Jude , myself >>>> Reviewed by: Allan Jude >>>> Approved by: re (glebius) >>>=20 >>> Hi Devin -- >>>=20 >>> As was discussed on the mailing list, this patch still has some issues >>> that need to be resolved, >>=20 >> Can you kindly provide links? I'm crawling through the mailing lists and >> not finding anything for the October, (current, stable, sysinstall, ... = ?? others?) >>=20 >> Do I need to be looking back in September? I wouldn't think so, because = that >> bit wasn't even in our development tree until October 1st: >=20 > This was discussion on freebsd-current from yesterday and the day before. >=20 Links or it didn't happen. HINT: I just (for the the third time on this topic) crawled the following: http://lists.freebsd.org/pipermail/freebsd-current/2013-October/thread.html Please help me find what you're talking about. >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net/= viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdconfig%253A%253Ashare%2= 53A%253Adevice.subr.patch?revision%3D1.1%26view%3Dmarkup&k=3D%2FbkpAUdJWZui= TILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%= 0A&m=3Daas9lyFMptmk4eQ3C74XXVkRHbiN19EOClxMMjoCuhE%3D%0A&s=3D9d21b812e49d92= 1455e998bde7c538318c3bfcc8759c1d0b61eede553b203865 >>=20 >> So there couldn't have been any discussion on it before then. So I'm jus= t not >> able to find the mailing lists where all the action is that they're disc= ussing it. >> Would be nice to find where the action is, so I could participate. >>=20 >>=20 >>> for example the use of camcontrol >>> unconditionally even when the disks may not be CAM >>=20 >> Allan Adds: >> 9.2 should have all disks listed in camcontrol, so it shouldn't be an is= sue >=20 > No it shouldn't. Not all disks are interfaced to CAM. MFI comes to mind, = nvme, VM block devices, SD cards. There are many other examples. OK... duly noted. Much thanks for dispelling that myth. > Just because you don't have them does not justify a phenomenological appr= oach here. >=20 Need I remind you... we don't *list* the disks from camcontrol... we just u= se it as a perfunctory value-add by stealing disk descriptions from it if/when it is describing a = disk. I would hardly call that phenomenological (rather, more of a multi-pass car= tesian ontological approach). >> And: >> I think the only systems without cam based disks are old 8.x - we're onl= y targeting 10 anyway. >=20 > Not true at all. >=20 Thanks. >> I tend to agree with those statements. >>=20 >>=20 >>> and destruction of >>> existing sub-partitioning for MBR disks. >>=20 >> I think we both (Allan and I) actually responded directly to you on this= one. >>=20 >> We have code that handles that. It's in there. >=20 > To me, yes, but I was wrong in my initial comment as pointed out by some = others. In particular, you need to run gpart -F destroy recursively on the = disk instead of just on the root node. There were several other issues and = bugs mentioned in people's cursory review of the patch. Where? by whom? and when? We've already established that it wasn't in the mailing lists (or at least = not in -current as you claim). > I never dreamed you would then just commit it. >=20 A great mentor of mine once said... "Practice makes Perfect? NO! Unattainable. [pause] Practice makes *improvem= ent*." Perfection versus Improvement. I would be hard-pressed to accept any argument that a regression has occurr= ed. > I really really don't want to have to subject installer changes to explic= it approval requirements, Threats won't help your cause. Civility is key. > but *please* request review of non-trivial changes before commits, especi= ally to the disk partitioning code, Didn't touch your disk partitioning code. I have zero plans to. You can keep it (I'll just replace it in-whole when I= have something better). > and especially again before insta-MFCing them to a stable branch right be= fore a release. Gleb gave me insta-MFC approval. > It is much, much better than having to do this after the fact as > we are doing now. What we are doing doesn't need to be done (period). --=20 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.