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