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

[Warner Losh]

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

> On Apr 25, 2011, at 9:29 AM, Alexander Motin <mav at 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 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.
>>>> 
>>>> 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.
>>> 
>>> Do we have a short list of the places to look? 
>> 
>> 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"`.
>> 
>>> 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...
>> 
>> 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, 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=t 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
> 
>