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 linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb