[linux-dvb] [PATCH][RFC] dvb-s2 support added to frontend.h

Johannes Stezenbach js at linuxtv.org
Wed Mar 29 00:44:56 CEST 2006

On Wed, Mar 22, 2006, Andreas Oberritter wrote:
> On Wed, 2006-03-22 at 18:55 +0100, Marcel Siegert wrote:
> > chose to have ioctls numbered NOT with the __FE_[GET|SET]_FRONTEND_OLD numbers,
> > after discussion with andreas oberritter. (think this needs more investigation/discussion)
> my last words during our conversation were that I agree with Felix that
> this will break compatibility for old apps which were compiled with new
> headers but are running on old kernels. So this is probably not an
> option.

The app might pass uninitialized data in the extended_parameters
field. One could tolerate this by having the driver disregard
the information until the app has called FE_SET_STANDARD.
I'm not sure it's a good idea, though.

> But I think you should write the word "HACK" next to it in large letters
> with flashing lights, because this style of backwards compatibility must
> not be copied blindly in the future. It only works in this case because
> the old and new structs happen to have different sizes which makes the
> ioctl macro create a different magic number. But the size of a structure
> depends on the architecture (e.g. 32 vs. 64 bit longs) and maybe on
> alignment restrictions. I guess there will be cases where such a change
> will work on an 32 bit x86 system, but won't on some other arch, let's
> say 64 bit alpha/sparc/ppc/mips.

I don't see any problem here. We have to implement 32/64 bit
ioctl conversion for the extended_parameters field, but that's
an implementation not an API issue.

> Maybe this has already been discussed, but in case it didn't: Why don't
> we leave the ioctl as it is now and introduce a new one additionally,
> e.g. FE_SET_FRONTEND2, and mark the old one as deprecated?

Because it's ugly?

But yeah, the hackish solution is also ugly :-(

Choose your poison...


More information about the linux-dvb mailing list