Johannes Stezenbach schrieb:
On Thu, Mar 02, 2006, Rainer.scherg wrote:
Johannes Stezenbach wrote:
I think it's more useful for the lib to query for specific
API/driver capabilites than for a version number.
Querying driver capabilities is of course necessary.
But a version information about the API version, too.
Currently is more or less guessing during compile time
what API is present. Using major/minor numbering scheme
we can tell an application (or user space library), if
it's able to run on a machine.
For compile time there is linux/dvb/version.h.
But the lib should support any kernel, so there
are two choices (pseudo code):
1. ioctl(FE_GET_VERSION);
if (api_version_minor > 1)
/* assume FE_SET_STANDARD is available */
2. ioctl(FE_GET_CAPS);
if (caps & FE_CAP_SET_STANDARD)
/* we know FE_SET_STANDARD is available */
My personal preference is 2.
"2." will work as long as there is no need to change
any data structures. Best example here is the switch from
DVB API v1 to v3. There is no safe method to check the
kernels dvb api version. OK, you could check device pathes
at runtime, as long they were not altered....
The only safe way is: get the source, compile...
Enabling an application to check the api version at runtime
has 3 advantages:
- application can do stop smoothly before crashing due
to wrong data structures
- application can do a fallback
- no effort to implement (no one gets hurt here)
"major number" would mean different API layout.
"minor number" changes are signalling enhancements/minor changes
e.g. an application build at a lower minor number should also
run on higher numbers.
The version checking feature IMO gives us more control to handle
enhancements of the API.
Also a word about what we discussed on IRC:
IMO we should take the chan[g|c]e to design a new dvb api here
e.g. "skip" v4 and start v4.1 or v5).
A "frozen" api v3 compatibility layer should be provided for
the new api, so older/current applications can be run without
redesign or code changes.
The new api doesn't need to follow api v3 (or v4) structures
(e.g. better use pointers instead of unions in some data
structures to get more flexibility to enhancements, etc.).
Rainer
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
