On 5/17/07, Johannes Stezenbach <js@xxxxxxxxxxx> wrote:
Hi Markus, On Thu, May 17, 2007, Markus Rechberger wrote: > On 5/17/07, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote: > > > >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. > > In that case I'm willing to fork the linuxtv project if I did too much > to review. > I just spent too much time on it to throw it away without a serious > discussion. > > The tuner refactoring code has around 600-700 lines of code I think, > the rest are the additional drivers and other things. After the recent flamewar there was the opportunity for you to get the whole thing merged, if you had only pushed it out in time. IMHO em28xx even could have made it into 2.6.22... Life is full of compromises, some of them ugly. Don't you think it would be better to scarifice those 700 lines of code in order to get the thousands of lines of em28xx and xc3028 code merged _now_? (And, BTW, you should not take this personal. The amount of code written for the kernel, posted to lkml and then mercilessly pulled to pieces, and finally thrown away is HUGE.) While certainly not ideal, Mike's plan is at least a way to make progress, even if there's a little detour involved.
I have some other work pending which relies on this too since I don't want to get stuck I want to get forward asap. The reason why I redid it back than was I tried to find a better solution and in case of that I'm fine with that solution now since it works flawlessly with the saa7134 and cx88 too. The last discussion before this one was to get the patches ready for merging with the upstream code, I exported it again and now again it's having a hard time. I just one more time spent another full day with doing and testing all that. This is not acceptable for me anymore, and I'm very sure that this time wasting mentality will go on with other projects too which join the current linuxtv project. I seriously discussed this way in private with some developers, surprisingly some of them had nearly the same idea as I wrote already. There are many ways devices can be built, there will never be one way which will cover all board designs, Manu listed some possibilities, maybe he should also have written what about devices which do not have a tuner either and are directly fed with input data. My current work is based on what is available now on the market. All the tuners which are written as dvb tuner modules at the moment are i2c tuners, using dvb_attach it's still possible to override the structs with completly different callbacks. I will not go back anymore, instead a fork off seems to be a good solution if the linuxtv project wants to stay stuck where it is at the moment it should do so. I'm very sure almost noone even had a look at the code. Since around 1 1/2 years there hasn't been any solution, linuxtv can go for another 10 years I don't mind but then without em28xx(analogue/digital) support which is very popular at the moment, and also lacking support for the xc3028 hybrid devices. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
