From owner-svn-src-all@FreeBSD.ORG Mon Apr 25 20:25:08 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 277441065676; Mon, 25 Apr 2011 20:25:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CA3418FC1D; Mon, 25 Apr 2011 20:25:07 +0000 (UTC) Received: from [10.30.101.54] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3PKKD11023681 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 25 Apr 2011 14:20:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com> Date: Mon, 25 Apr 2011 14:20:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <4DB441B0.8020906@FreeBSD.org> <20110425134531.GA4391@garage.freebsd.pl> <50385B7B-7EC8-4BC3-8F88-83F9EB4096FB@bsdimp.com> <4DB5A166.9010302@FreeBSD.org> <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 25 Apr 2011 14:20:15 -0600 (MDT) Cc: "src-committers@FreeBSD.org" , Pawel Jakub Dawidek , Alexander Motin , "Bjoern A. Zeeb" , Robert Watson , "svn-src-head@FreeBSD.org" , "svn-src-all@FreeBSD.org" Subject: Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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: Mon, 25 Apr 2011 20:25:08 -0000 On Apr 25, 2011, at 1:16 PM, Garrett Cooper wrote: > On Apr 25, 2011, at 9:29 AM, Alexander Motin wrote: >=20 >> Warner Losh wrote: >>> On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote: >>>> On Sun, Apr 24, 2011 at 06:59:40PM +0000, Bjoern A. Zeeb wrote: >>>>> I had been pondering devfs "link"s myself, the problem is that = from the rc >>>>> framework they come too late. If you can add a simple .ko that = does it >>>>> programmatically on 9 that would be great. The problem is that = after booting >>>>> the new kernel you don't know whether people had ATA_STATIC on or = not, so >>>>> we'd have to go with the defaults, that were in 8.x (and an extra = tunable to >>>>> flip the logic maybe)? >>>> We do know that people have ATA_STATIC_ID, because if they don't, = this >>>> means they have their custom kernel config which doesn't contain = ATA_CAM >>>> and when they will use it next time they recompile their kernel = they >>>> will still have /dev/adX entries. >>>>=20 >>>> Also, as Alexander already noted, because of all the problems with = ATA >>>> naming over the years and for other reasons too, people often = hardcode >>>> provider name in various GEOM classes metadata, so symlink won't = help. >>>=20 >>> Do we have a short list of the places to look?=20 >>=20 >> Quick man pages grepping shows that at least gmirror, gstripe, = graid3, >> gjournal, gvirstor, gconcat, gshsec support provider names = hardcoding. >> For gmirror and graid3 present status can be obtained by: `gXXX list = | >> egrep "Flags: .*HARDCODED"`. For gvirstor, gshsec, gstripe and = gconcat: >> `gXXX dump adX | egrep "Hardcoded provider: ad"`. For gjournal: >> `gjournal dump adX | egrep "hcprovider: ad"`. >>=20 >>> A lot of this could be done with a script that gets run at = installworld and boot time to hunt down the old cases and report them to = the user before they upgrade their kernel (but this would mean backing = out the GENERIC change for a while to give people a chance to upgrade to = label-based provisioning... >>=20 >> If I understand idea right, independently of how much we delay it, = there >> will be some people who not updated during that window to get in code >> detecting it during boot. Hardly many people of target auditory = updating >> their systems each month. Same time some checks indeed could be done = in >> installkernel. >=20 > For people like me who install multiple kernels and boot them at will, = especially when there are other features under a large degree of = development, this kind of action isn't acceptable because it shoots you = in the foot when moving between the different kernels. No it doesn't. (a) There will be an override flag, if you really don't want to. = WITHOUT_FSCK_SANITY_CHECK=3Dt and we're done. (b) The /dev/ufsid/*,/dev/gpt/*, /dev/ufs/* naming works on both flavors = of kernel. > I'd prefer having an UPDATING note with all of the affected areas so = that people can understand what needs to change and adjust their systems = accordingly. As far as geom based hardcoding is concerned: maybe this = can serve as a good lesson of what shouldn't be done and what should be = fixed/have a translation layer added for this item? I'd prefer having it be there also. Warner > Thanks, > -Garrett >=20 >=20