On 03/24/10 08:50 AM, Sebastien Roy wrote:
> On 03/24/10 11:31 AM, Garrett D'Amore wrote:
>> On 03/24/10 08:19 AM, Sebastien Roy wrote:
>>>
>>>>
>>>> Right now the framework just ensures that the version number matches.
>>>> Conceivably in the future this could be used to detect the need
>>>> for, and
>>>> enablement of, a compatibility layer perhaps like the GLDv2 used to do
>>>> for GLDv0 drivers. More likely, it would be used in a manner like the
>>>> devops version to detect when the ops structure grows new fields.
>>>>
>>>> Until we have a need for an incompatible interface change, I can't
>>>> know
>>>> for sure exactly how versioning will work, but only speculate. The
>>>> version number for now is just a way to enable this some basic
>>>> insurance
>>>> against whatever the future may hold for now.
>>>
>>>
>>> That's fine, but where is this version number? I hinted above that I
>>> thought that there was some documentation missing. Did I miss it?
>>
>> If you look in audio_engine_ops.9s in the case materials, you'll see
>> audio_engine_version is the first member of the structure.
>
> Ah, I see thanks. Also (FYI), the reason I missed the description of
> audio_dev_set_version() in your materials is because there's a typo in
> audio_dev_set_description.9f (where it's called audio_dev_version()).
>
> Anyway, +1.
>
> -Seb
Thanks for the catch. "audio_dev_set_version" is intended for human
readable information about the device, and has nothing to do with
interface versioning. Hopefully that was clear.
- Garrett
