Hi Theodore, On Fri, 20 Feb 2009 19:30:16 -0600 (CST) kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote: > Hoping that I can offer some helpful comments on this thread, as someone > who came along only in the last couple of months or so: > > 1. One of the most interesting features which I found in the video for > Linux project is the ability to work somewhat independently of the > particular kernel version running on the local machine. This is valuable, > in the sense that it saves a lot of wasted time and effort just keeping up > with which kernel version to use. It was also something which is done so > cleverly that at first I could not believe it. Congratulations to those > who thought this arrangement up. > > 2. Sometimes, there is a real problem with a particular version of the > kernel which has nothing to do with the task at hand, but it sure can get > in the way. As a recent example, soon after starting to work with Adam > Baker on the sq905 module (and furthermore having at the time the false > impression that the gspca work meant I should be running the latest thing > out there) I upgraded from 2.6.27.7 to 2.6.28. Well, there was a rather > serious USB bug in 2.6.28. So then _that_ had to be straightened out. > Things like that do not promote smooth progress but rather interfere with > it. > > 3. I just bought an eeePC. It is running some 2.6.21.x kernel. My > reaction: I do not believe they should be doing that. I would not feel > like accommodating them. Comparison: someone wrote to me complaining about > problems with libgphoto2-2.1.3, which his distro was still releasing, when > libgphoto2-2.3.x was already out and his problem had been solved 24 months > before. I told him to upgrade and his problems would go away. He wanted me > to fix his old version. I explained that this has been done, and he should > avail himself of that by installing a new version. Somewhere there is a > line, and that guy crossed it. > > Trying to put all this together: > > I think that the semi-independence from the particular kernel-du-jour is a > good thing and would seem to me to make progress in the specific area of > video to be smoother. Modular or semi-modular development is something > nice. One can concentrate on the subject at hand and not on daily kernel > upgrading. Nice. > > I also would not want to bust my butt to support someone's ancient kernel. > After all, quite often the reason there is a new kernel version is that > some long-undiscovered bug suddenly got discovered. Not all change is > just for fun, or just to support new stuff. Some of those bugs had > far-reaching consequences, recall. So to support one of the affected > kernels involves what, exactly? > > Hoping that these comments help toward some good conclusion of this issue. Thank you for your comments. For sure allowing to compile v4l-dvb with older kernels is very interesting for the users. It is not perfect, since a bug upstream will keep affecting the backported driver, but, in general, this works well, however, at the cost of spending developers time backporting things. Since the size of the tree is increasing a lot, we'll likely need to use another solution. 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
