On Wed, 18 Feb 2009 09:55:53 +0100 (CET) "Hans Verkuil" <hverkuil@xxxxxxxxx> wrote: > Not at all. I work with embedded systems and what happens is that you > effectively take a kernel snapshot for your device and stick to that. > You're not using v4l-dvb, but you might backport important fixes on > occasion. > > Again, it's not our job. The linux model is to get your drivers into the > kernel, then let distros take care of the rest, which includes backporting > if needed to older kernels. We are doing the work that distros should be > doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the > express purpose to be finally free of keeping it backwards compatible with > older kernels. Now I find myself doing the same AGAIN. > > And you are talking about that mythical user that needs it. I've yet to > SEE that user here and telling me that it is essential to their product. > > PROVE to me that it is really necessary and really our job, and esp. my > job, since *I'm* the one keeping the backwards compatibility for i2c > modules alive. All I hear is 'there might be', 'I know some company', 'I > heard'. > > Right now there is crappy code in the kernel whose only purpose is to > facilitate support for old kernels. That's actually against the kernel > policy. > > One alternative is it create a separate repository just before the compat > code is removed, and merge important fixes for drivers in there. That > should tide us over until RHEL 6 is released. > > Which also raises the other question: what criterium is there anyway to > decide what is the oldest kernel to support? RHEL 5 will no doubt be used > for 1-2 years after RHEL 6 is release, do we still keep support for that? > Old kernels will be used for a long time in embedded systems, do we still > keep support for that too? Hans, I'm doing backport since 2005. So, you are not the only one that are doing backports. On V4L, this started ever since. In the case of DVB, we started backport on 2006. Before that, they use to support only the latest kernel version. If you get a snapshot of our tree of about 6 months to one year ago, we had even support for linux-2.4 I2C (and yes, this works - I have a tree here for vivi and bttv drivers based on that i2c support, working with 2.4). In the past, our criteria were simply to support all 2.6 versions and the latest 2.4 versions. Sometime after having the last 2.4 distro moving their stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep 2.4 on that time. Maybe the current solution for i2c backport is not the better one, and we need to use another approach. If the current i2c backport is interfering on the development, then maybe we need to re-think about the backport implementation. The backport shouldn't affect the upstream. It were never affected until the recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even having a completely different implementation on 2.4. > The only reasonable criterium I see is technical: when you start to > introduce cruft into the kernel just to support older kernels, then it is > time to cut off support to those kernels. The criteria for backport is not technical. It is all about offering a version that testers with standard distros can use it, without needing to use the latest -rc kernel. I'm fine to drop support to unused kernels, but the hole idea to have backport is to allow an easy usage of the newer drivers by users with their environment. If we start removing such code, due to any other criteria different than having support for kernels that people are still using on their desktop and enterprise environments, then it is time to forget about -hg and use -git instead, supporting only the latest tip kernel, just like almost all other maintainers do. While we are stick on have backport, we need at least to support the latest desktop and enterprise kernel versions of the major distros. So, it is a matter of deciding what we want: keep our current criteria of offering backport kernels that include at least the kernel version used on the major desktop and enterprise kernel distros OR just use -git and drop all backport code. Both solutions work for me, although I prefer to keep backport, even having more trouble[1]. Anything else and we will enter of a grey area that will likely go nowhere. [1] Side note: i2c is not the only subsystem whose changes affect our tree. I have on my TODO list a backport on dvbnet, due to some net changes at 2.6.29-rc: $ diffstat /tmp/diff dvb_net.c | 57 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 28 insertions(+), 29 deletions(-) In this case, several data that used to be stored on one struct moved to another. So, if applied as-is, it will just break support for all kernels lower than 2.6.29 on all drivers that supports DVB. On the other hand, our -hg trees don't work with 2.6.29-rc. Cheers, Mauro -- 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
