Re: Old ATA disk names emulation [Was: Switch from legacy ata(4) to CAM-based ATA]

Marius Strobl wrote:
> On Mon, Apr 25, 2011 at 01:23:37PM +0300, Alexander Motin wrote:
>> I've implemented following patch to keep basic compatibility for the
>> migrating users. I don't like such hacky things, but at least I tried to
>> make it less invasive.
>>
>> The idea:
>>  - New xpt_path_legacy_ata_id() function in CAM tries to predict bus
>> unit number and then device unit number for specified path, as if it was
>> with legacy ATA with ATA_STATIC_ID option.
>>  - on attach, ada driver fetches that number (if not disabled using
>> tunable kern.cam.ada.legacy_aliases), prints to console something like:
>> ada0: Previously was known as ad12
>> , and sets kernel environment variable like:
>> kern.devalias.ada0="ad12"
>>  - when geom_dev tastes new geom and creates device node for it, it also
>> tries to match prefix of the device name with present kern.devalias.*
>> enviromnent variables, and, if some match found, creates alias with
>> substituted name (ada0 -> ad12, ada0s1 -> ad12s1, etc.).
>>
>> The patch is here: http://people.freebsd.org/~mav/legacy_aliases.patch
>>
>> I did few tests and it seems like working -- two sets of device nodes
>> appeared for each device, I can successfully label and mount any of them.
>>
>> What will not work:
>>  - old device names won't be seen inside GEOM, so users who hardcoded
>> provider names in gmirror/gstripe/... metadata (not the default
>> behavior) are still in trouble.
>>  - patch mimics ATA_STATIC_ID behavior, if user had custom kernel
>> without it, he should update device names manually.
>>  - it won't work for users with hot-unplugging ATA controllers (not
>> devices), but I believe it is really rare case.
>>  - low-level tools, such as smartmontools, won't be able to work with
>> alias devices, as background ada driver doesn't implements legacy
>> ioctls. May be I could partially fix this.
>>
>> Except those, I think this patch should work for the most of users.
>>
>> Any more objections/ideas? Is this an acceptable solution?
> 
> given that only the amd64, i386 and pc98 GENERIC kernel configuration
> files had ATA_STATIC_ID enabled by default it would be highly desireable
> that your compatibility shim also only mimics that behavior on these
> archs or probably better actually check for ATA_STATIC_ID and put that
> option back into the respective kernel configuration files.

You are right. I have also thought about restoring that option, but
haven't related it with architectures.

-- 
Alexander Motin