[linux-dvb] [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c]

Alan Nisota alannisota at gmail.com
Sun Apr 16 16:05:17 CEST 2006

On 4/15/06, Alan Nisota <alannisota at gmail.com> wrote:

> I made some assumptions about your intentions and completed the
> implementation in dvb_frontend.c.  I then finished off the driver, but
> I haven't been able to test yet, as I still need to update mythtv to
> support the new ioctls.
After working on updating mythtv, I must admit that I am unhappy with
the API extension for DVB-S2 that Marcel is proposing.  The
extended-info stuff is fine, and doesn't cause any issues, but the
fact that dvb_parameters_new is not backwards compatible (the union is
dynamically allocated) means that apps need to implement completely
different code to implement the new API.  Since they'll never be able
to stop using the original dvb_parameters (how many years until 90% or
more of the users have moved to a kernel newer than 2.6.18+?) all apps
will either continue using the current api for already-supported
protocols, and use the new ones only for the new protocols, or will
have two entirely separate DVB implementations, so you are forcing a
lot of additional work and maintenance headache on them.  In myth
specifically, the code becomes extremely ugly with many #ifdefs to
support dvbs2.
If dvbs2 had been added to dvb_parameters, or if dvb_parameters_new
was backwards compatible, the numbers of these would drop
significantly and it would be easy to switch to the new API if present
for all methods without duplicating a huge amount of code.  Also, I
think deprecating dvb_parameters makes no sense to me.  Since many
apps won't support the new API, SET_FRONTEND and friends will be
around for a long time.  since the functions which implement that
ioctl require dvb_parameters, I don't see a way to remove the calls. 
So all that deprecating it does is add lots of useless warnings to the
kernel compile.

Specifically for myth, if the current way is deployed, we could
isolate anything that deals with dvb_parameters, and be able to switch
between access functions, which would minimize the work required to
support both APIs, and would make it possible to switch entirely to
the new one, if it is available, without a lot of overhead  This will,
however, involve a rather substantial patch which would not otherwise
be required.

More information about the linux-dvb mailing list