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 10: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 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"`.
> 
> That wouldn't be too horrible...
> 
>>> 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.
> 
> We'd have to delay it at least a month, if not more.  However, the time to have done these checks were 8.1ish rather than 9.0 nearing code-freezeish.  I'd thought there was going to be better compatibility last year at this time, or I'd have pushed this idea harder in the community...
> 
> And yes, I'd envisioned installkernel also doing these checks, just to be complete and prevent foot-shooting.  At this point, it's all we have.  For the 9.0 install, we'll likely need to do a subset of this as people import their gmirrors created with 8.x...

I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the "symlinking" way (patch
is already posted to current@), I think it will be much easier for
everybody, and especially users, if I hack all mentioned above GEOM
classes to ignore adX/adaY difference in provider names. And it should
perfectly fit into remaining time window.

-- 
Alexander Motin