Mauro Carvalho Chehab wrote: > >> I do frown upon code duplication, however, in this case it is a safer >> alternative to the one currently on the table. Earlier versions of >> the xc3028 tuner driver were bound to the video4linux tuner.ko >> module, for the sake of tuning analog television stations. There was >> a wrapper present inside the em2880-dvb driver that allowed the dvb >> subsystem to access the xc3028 via tuner.ko. I am not a big fan of >> this solution, however, it does not touch any core subsystem code. >> DVB-only devices can use a separate module in order to access the >> xc3028 without imposing dependencies on the v4l core. > > Duplicating a driver is not a solution, just a terrible hack. We > should focus on a way to use the same tuner driver for both Analog and > Digital TV. > Mauro, Don't get me wrong -- I am not suggesting that we duplicate this code and leave it in that state forever. What I am suggesting is that we go about this change in small steps. The proposed changes are simply too large and span too many source files to achieve a proper review by enough developers, especially in their "spare time," not to mention all the regression testing that needs to be done. As much as we try to come to an agreement about this right now, I fear that it will be very difficult -- this debate has gone on for over a year and reaching an agreement will not be easy. I think that the only way to move forward while keeping everybody happy would be to proceed in the following order: 1) merge xc3028 support into tuner.ko for analog support* 2) break apart tuner.ko into modularized sub-modules* 3) add xc3028-fe.ko module for dvb-only support** 4) merge in updates to the em28xx driver*** 5) add xc3028 support to other card drivers*** 6) restart discussions about hybrid / tuner inter-subsystem API 7) apply changes agreed upon in step 6, to migrate the tuner modules to the new tuner internal api, while removing the duplicated xc3028 module. *(1) and (2) may be reversed ** http://linuxtv.org/~mkrufky/xc-bluebird.patch *** analog functionality should use tuner.ko only *** digital functionality should use xc3028-fe.ko only --- Please take note, that if we proceed in the order above, this will allow us to merge the majority of Markus' changes, leaving only the api changes behind. At this point, the remainder of the changesets will be MUCH smaller, and much easier to review. Under the conditions that we'll be under after step 5, it will be much more conducive to a productive developer discussion on the issue. At this point, there has been so much noise about this topic, that I feel confident that many developers will be able to participate in this review. I, for one, would love to have this taken care of, and put this issue behind us. After step 5, with the majority of the changesets already being merged, the pressure on the author and reviewers will be lessened, and discussions should be able to take place with clear heads. What I am asking for here is very sensible -- This should not be difficult for everybody to agree to. It allows us to merge in changes one step at a time, while adding support for all devices gradually. Through this means, we will ultimately achieve the goal of being able to discuss the actual requirements and reasons for why Markus is making this proposal to change the tuner api. I repeat: huge changes will never blow over well. The only way to do this in small steps is to do it in such a way that I've described in this email. If you simply shoot me down for the idea of temporarily having a separate dvb module for the dvb subsystem to interface with the xc3028 tuner, then you are not seeing the big picture. Regards, Mike Krufky _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
