On Sunday 16 April 2006 16:05, Alan Nisota wrote: > On 4/15/06, Alan Nisota <alannisota@xxxxxxxxx> 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. hi for the 3rd time :) what way should be preferred? breaking compatibility or stay at old api capabilities having no way support for dvb-s2. (ok, there's one way, but that would be an ugly solution also) > 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. i do know that we may have code duplication on user side. but, imho an advantage would be, _not_ having the same issues if the next standard comes to our knowledge. e.g. dvb-c2 dvb-t2 ... > 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. marking something deprecated isn't the right solution all the time. but in this case it is signalling that there has been an api change/extension and old features/functions should be replaced by the developer. if i would not mark it deprecated, nobody will start to use the new ioctls. simply due to the fact, that nobody would maybe even get known of changes, except if they will support dvb-s2. > 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. normally i also do development on an application that uses e.g. dvb api v3, directfb, ect. maybe it is a matter of code design, that we don't have to patch a huge amount of source code. we organised it in a different way. best regards marcel _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
