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