On Tuesday 24 February 2009 06:04:48 Trent Piepho wrote: > On Mon, 23 Feb 2009, David Ellingsworth wrote: > > On Sun, Feb 22, 2009 at 5:15 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > Optional question: > > > > Why can't we drop support for all but the latest kernel? > > > > > Why: > > > > As others have already pointed out, it is a waste of time for > > developers who volunteer their time to work on supporting prior kernel > > revisions for use by enterprise distributions. The task of > > back-porting driver modifications to earlier kernels lessens the > > amount of time developers can focus on improving the quality and > > stability of new and existing drivers. Furthermore, it deters driver > > development since there an expectation that they will back-port their > > driver to earlier kernel versions. Finally, as a developer, I have > > We don't backport the drivers to older kernels. That's what drivers kept > in a full kernel tree end up doing. > > Generally there is just the code for the newest kernel to think about. > Most of the driver code doesn't have backward compatibility ifdefs. Most > of the compat issues are handled transparently by compat.h and only those > developers who patch compat.h ever need to know they exist. > > When a developer does need to deal with some compat ifdef in a driver, > almost all the time it's something trivial and obvious. Change the > variable name in both branches. Copy in a couple lines of boilerplate. > > Sometimes a bigger issue comes up. IIRC, around 2.6.16 there was a major > class_device change in the kernel and backward compat code for it ended > up being a nightmare. So we didn't do it. We stopped supporting back to > ~2.6.11 and moved up the target past the problem change. Actually that was in 2.6.19. The class_device #ifs are still in e.g. v4l2-dev.c. It would be a nice bonus when we can drop that as well. It could be that there were additional changes as well in pre-2.6.16 kernels. If so, then we definitely implemented the backwards compat for it at the time. > Maybe this has happened again with the changes to i2c? I don't think > it's that hard, but I've yet to do it myself, so maybe it is. I've been working on this since around 2.6.24 (and been involved with i2c in one way or another for quite a bit longer) and I say it's hard. Jean Delvare made the i2c core changes in 2.6.22 and he says it's hard. So perhaps if the two people who know most about the topic say it's hard and not solvable with a compat.h change, or the occasional #if, or a regexp as Mauro seems to be attempting now, then it really IS hard. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
