On 03/24/10 11:02 AM, Garrett D'Amore wrote: > On 03/24/10 07:01 AM, Sebastien Roy wrote: >> Garrett, >> >> The only question I have on this case is how versioning works. Are >> there provisions in the API to handle drivers compiled on an older >> version by either failing gracefully or by transparently handling >> multiple versions? I can't tell from the materials if the >> audio_dev_set_version() function is meant to be relevant to this >> question as I didn't find the documentation for that function in this >> case nor in prior Boomer cases. >> >> -Seb > > > 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? -Seb
