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

Marcel Siegert mws at linuxtv.org
Thu Mar 30 21:18:46 CEST 2006


On Wednesday 29 March 2006 00:44, Johannes Stezenbach wrote:
> 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.

i don't know either.

 
> > 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...

i'll take the "hackish" solution. but i will remark it as a hack.

> 
> Johannes
> 

marcel




More information about the linux-dvb mailing list