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