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]

On 24.04.2011 21:59, Bjoern A. Zeeb wrote:
>> What's about creating some kind of symlinks, it could be nice if it
>> worked, but I don't see the way to do it on disk(9) or GEOM layers
>> without breaking device's access counters and as result further random
>> problems.
>
> 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)?

Devfs links won't help users with hardcoded provider names in gmirror, 
etc -- from GEOM PoV there will be no such providers. Also to create 
proper mapping that module should have real-time information from CAM 
about ATA controller details. And looking that it will have to link in 
real time any derivative providers also (ad4s1a -> ada0s1a) I worry if 
it is possible at all. Some devfs expert needed here.

>> Looking now on these "do or revert" demands to keep old device naming,
>> I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX"
>> names. I see it in form of some loader tunable, disabled by default (as
>> it should be on newly installed systems), but that could be set prior to
>> upgrade if user doesn't want to bother with device names at that moment.
>> It should partially hide problem for some time.
>
> It would need to be in and on by default for the lifetime of 9 as it's not
> in the last 8.x release (which would need it the other way round anyway.
> MIght it be a good idea to do that as well afterwards providing ada links
> on the next 8.x release?).

I wouldn't like to keep that ugly numbering on by default till the 9.x 
EoL even for new installations. Also remember about number of people 
already using new ATA, for whom requirement to disable that tunable may 
also be uncomfortable.

> The user could disable it after the conversion happened though with a tunable
> to get rid of the extra /dev/* noise.  We could even check for it being on
> and check fstab and warn/pester the user then that he'll need to migrate
> (on boot from rc.d, in weekly mails, ...).

It would be fine if it was just devfs noise, but I have some doubts 
about it (above).

> If we have both information available (old from the kernel transition code)
> and new we could even provide a script to do it.
>
> The reason we might not want to do it automatically is that if the user will
> decide to boot kernel.old because the new kernel panics after 2 days, she'll
> be facing the new ada entries in fstab with an 8.x kernel and that would not
> work either.   So it's a decision users need to make eventually themselves
> during the lifetime of 9.x when upgrading from an older release.

Reasonable.

>> Will such solution be acceptable?
>
> I think any solution will be acceptable if it (mostly) works and gets the
> possible fallout rate (significantly) down and thanks a lot for picking it
> up now!

But that solution should not include setting tunables before upgrading? 
Can't we teach mergemaster or whatever else to set it depending on whet 
disks are now present in system?

> PS: And I think you'll find a lot of testers the next days/weeks on current@
> when people update their kernels and forgot to read UPDATING or fail to
> do the conversion properly.;)

I can always say: "read UPDATING" (for log: I am not completely serious 
here. :)).

-- 
Alexander Motin