> Hans, > > On Mon, 2 Mar 2009 22:18:24 +0100 > Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > In the final analysis I'm the boss of my own time. And I've decided that > > once the conversion of all the i2c modules is finished I'll stop > spending > > time on the compatibility code for kernels <2.6.22 as it is simply no > > longer an effective use of my time. If someone else wants to spend time > on > > that, then that's great and I will of course answer questions or help in > > whatever way is needed. > > > > I know that Mauro thinks he can keep the backwards compat code in by > doing > > nifty code transformations. It would be nice if he succeeds (and I have > no > > doubt that it is possible given enough time and effort), but personally > I > > think it is time better spent elsewhere. > > It required just a couple of hours today, in order to add the I2C > conversion > rules on the backport tree: > > http://linuxtv.org/hg/~mchehab/backport/ > > There, I used, as example, the tea6415c.c file that you sent me, meant to > be an > example of a driver converted to use just the new I2C API. I've removed > from it > all the other #ifdefs for 2.6.26, so, the module doesn't have any compat > bits > (except for "compat.h" that can also be handled by the script). I didn't > compile > the entire tree, since several drivers will break, as they aren't ported > yet > to the new I2C style. > > Maybe a few adjustments on the backport.pl may be needed, after having all > drivers converted to 2.6.22, since the final version may need some other > patching rules. > > That's said, the backport tree is still an experimental work. The scripts > require more time to be tested, and the Makefiles need some cleanups. Mauro, neat, but I still think time spent on backporting work would be better spent on cutting-edge development. Two hours here ... two hours there ... it all adds up to a significant investment of time. > Beside the fact that we don't need to strip support for legacy kernels, > the > advantage of using this method is that we can evolute to a new development > model. As several developers already required, we should really use the > standard -git tree as everybody's else. This will simplify a lot the way > we > work, and give us more agility to send patches upstream. Great! Do you have a plan for how soon a move to the standard git tree will happen? The sooner the better IMO. > With this backport script, plus the current v4l-dvb building systems, and > after > having all backport rules properly mapped, we can generate a "test tree" > based on -git drivers/media, for the users to test the drivers against > their > kernels, and still use a clean tree for development. > > Cheers, > Mauro If I understand correctly you are suggesting that a backporting system would continue to exist? Why? Surely this would be a heavy ball-and-chain to drag around for eternity. Why not lose the backporting and go for the simplicity and agility you mentioned above? Regards, Hans W. -- Release early, release often. Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
