[s]sd-config-list version 2 and retry count tuning [PSARC/2007/505 FastTrack timeout 09/11/2007]

[yu larry liu]

> The property encoding being revised seems particularly error prone --
> you need to define a bitmask and then an sequence of values where bit N
> of the bitmask tells the driver to look at value N in the sequence.
>
>   
We didn't change the syntax for property encoding from version 1.  I 
agree with you it is error prone. But it is simple and efficient. And it 
leaves door open to future version development. If splitting the 
properties, it will be complex for the combination of VID, PID and 
single property.  Any suggestion?
> If you're going to revise the encoding to be consistent across
> platforms, it also seems like it might be a good opportunity to make it
> less administrator-hostile in other ways.
>
> On Tue, 2007-09-04 at 07:56 -0700, Mark Carlson wrote:
>   
>> Those bits that only exist in version 1 are obsolete in version 2.
>>     
>
> we generally closely review proposals which remove functionality or
> declare it obsolete; can you enumerate the set of removed bits and
> explain why it's appropriate to remove each tunable?
>
>   
fabricate device id:  This is the case of antiquated Sun disk drives.
disable caching:      This is a historic behavior.
play BCD:
read sub-channel BCD:
read TOC TRK BCD:  These three are for binary-coded decimal CD device.
no READ_HDR:    This is not used at all. Even in version 1
read CD XD4:         This is to use command supported by 1st generation 
atapi drives
TUR check:             This is specific to some Seagate elite1 TQ 
devices get hung with disconnect/reconnect timeouts when they receive a 
TUR and the queue is not empty.            

All the bits above are Project Private. And they are for some specific 
old devices.

In version 2, we plan to only support those properties defined in 
sd_tunables table which is commonly used.
> Will the removed bits be turned into no-ops, or will they continue to be
> settable via a version 1 encoding?
>
>   
They are continuously supported via a version 1 encoding.
>> For a given vender ID and
>> product ID string, if both version 1 and version 2 are found,
>> version 2 will take effect. 
>>     
>
> I'm missing how that's possible given the encoding described in this
> case and in 2001/692 -- can you show an excerpt of [s]sd.conf syntax
> showing this ambiguity?  
>   
[s]sd-config-list = "SUN      T4", "t4-data"; "SUN      T4", "t4-data1";
t4-data=1,0x20000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1;
t4-data1=2,0x20000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1;

Thanks,
Larry