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

[Alexander Motin]

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.

-- 
Alexander Motin