Date: Mon, 25 Apr 2011 12:16:22 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Alexander Motin <mav@FreeBSD.org> Cc: "src-committers@FreeBSD.org" <src-committers@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, "svn-src-all@FreeBSD.org" <svn-src-all@FreeBSD.org>, "Bjoern A. Zeeb" <bz@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, "svn-src-head@FreeBSD.org" <svn-src-head@FreeBSD.org>, Warner Losh <imp@bsdimp.com> 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 Message-ID: <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com> In-Reply-To: <4DB5A166.9010302@FreeBSD.org> References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <alpine.BSF.2.00.1104241140070.36270@fledge.watson.org> <4DB441B0.8020906@FreeBSD.org> <CD028561-B550-4896-BE65-7C827BE6A34A@FreeBSD.org> <20110425134531.GA4391@garage.freebsd.pl> <50385B7B-7EC8-4BC3-8F88-83F9EB4096FB@bsdimp.com> <4DB5A166.9010302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 25, 2011, at 9:29 AM, Alexander Motin <mav@FreeBSD.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11B524F2-70D6-4B8A-BC7C-005EB5D6E393>