On Sun, Sep 16, 2007, Rainer.scherg wrote:
>
> - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when
It is necessary in the same way as you have KERNEL_VERSION
or GLIB_MAJOR_VERSION etc.
> distributing binaries (one of the bad things on linux are
> incompatible API changes over time).
> A simple major.minor version number check will IMO do.
We dicided against it since a capabilities based interface
is much nicer to use. Or a simple "try new ioctl, if that
returns ENOTTY use old ioctl" approach...
> - a "user structure" for hardware specific data (e.g. retrieve
> special data from a special frontend chip would be nice.
> this should be optional (*NULL = not used or not implemented).
> otherwise something like:
> struct { char[xx] hw_info;
> specific data...
> } *;
I think this API sucks. DVB API V1 had a "read/write demod register"
ioctl for debugging, which was removed because you could also use
i2c-dev. It would be better to find a way to use i2c-dev with
proper locking wrt fe->sem than to cram arbitrary and probably
unspecified hw data with unversioned layout into the DVB API.
> - API 3 is missing a a function for retrieving current frontend
> settings (e.g. on SAT LNB settings). It would be sufficient, when
> simply the last parameters set are returned.
> Currently on API3 a "second dvb application" can change the frontend,
> whithout any chance for the "main dvb application" to detect this
> easily.
As already outlined by Manu it doesn't work. DiSEqC command
strings can be of arbitrary length, we don't buffer this in the driver.
Johannes
_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
