From owner-svn-src-head@FreeBSD.ORG Mon Apr 25 19:16:37 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0F951065670; Mon, 25 Apr 2011 19:16:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43E818FC14; Mon, 25 Apr 2011 19:16:37 +0000 (UTC) Received: by pwj8 with SMTP id 8so1752716pwj.13 for ; Mon, 25 Apr 2011 12:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=14eX7lr2Gjz4DDYr6VnS3uFqoxq4CXGGfgn/VDAAdFc=; b=dvustF1/4GcYxAekDjWxDHE02MJFia6qG7nKgcvzmWPciln5iWg7pGn+iTfjSq1F4Q aS//eF4FN8lK5YeVaqZ0W6T3sxQVXwj+cct2eLYB5cR3oXisCpJVvcIu8qKUV66JaqPG FzHaZm8j7DhEe3PODSB03Oc8vLZZ1AdxkT6bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=UCqT4Vk75C9whk7CvAegepdIRycUT5WpriIi6zGTLBlZ4u61/LR3RZcv2JVtAIyMOS GhdzfDzKDPWa12CgHAB3svpFw//UlX49iOTO2Ll7061PSdr13r5YRDF03yi3mR6iXLOJ 5t3ORb0sOthBmLOIZXjGUUc+T3ED+wlyH2768= Received: by 10.142.151.4 with SMTP id y4mr2927244wfd.133.1303758996950; Mon, 25 Apr 2011 12:16:36 -0700 (PDT) Received: from [10.64.171.124] ([166.205.143.68]) by mx.google.com with ESMTPS id w14sm7257579wfh.8.2011.04.25.12.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 12:16:35 -0700 (PDT) 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> In-Reply-To: <4DB5A166.9010302@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com> X-Mailer: iPhone Mail (8C148) From: Garrett Cooper Date: Mon, 25 Apr 2011 12:16:22 -0700 To: Alexander Motin Cc: "src-committers@FreeBSD.org" , Pawel Jakub Dawidek , "svn-src-all@FreeBSD.org" , "Bjoern A. Zeeb" , Robert Watson , "svn-src-head@FreeBSD.org" , Warner Losh 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-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:16:38 -0000 On Apr 25, 2011, at 9:29 AM, Alexander Motin wrote: > 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 b= ooting >>>> the new kernel you don't know whether people had ATA_STATIC on or not, s= o >>>> we'd have to go with the defaults, that were in 8.x (and an extra tunab= le 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 a= nd boot time to hunt down the old cases and report them to the user before t= hey 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. For people like me who install multiple kernels and boot them at will, espec= ially when there are other features under a large degree of development, thi= s kind of action isn't acceptable because it shoots you in the foot when mov= ing between the different kernels. I'd prefer having an UPDATING note with all of the affected areas so that pe= ople can understand what needs to change and adjust their systems accordingl= y. As far as geom based hardcoding is concerned: maybe this can serve as a g= ood lesson of what shouldn't be done and what should be fixed/have a transla= tion layer added for this item? Thanks, -Garrett=