Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Apr 2011 14:20:08 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Garrett Cooper <yanegomi@gmail.com>
Cc:        "src-committers@FreeBSD.org" <src-committers@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>, Alexander Motin <mav@FreeBSD.org>, "Bjoern A. Zeeb" <bz@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, "svn-src-head@FreeBSD.org" <svn-src-head@FreeBSD.org>, "svn-src-all@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
Message-ID:  <C3BC50BC-E3E6-4DC8-966C-EC0E881204CD@bsdimp.com>
In-Reply-To: <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com>
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> <11B524F2-70D6-4B8A-BC7C-005EB5D6E393@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 25, 2011, at 1:16 PM, Garrett Cooper wrote:

> On Apr 25, 2011, at 9:29 AM, Alexander Motin <mav@FreeBSD.org> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3BC50BC-E3E6-4DC8-966C-EC0E881204CD>