Re: Results of the 'dropping support for kernels 2.6.22' poll
On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote: When this thread was started, it was about dropping support for kernels 2.6.22. However, it has turned into a thread about moving to git and dropping support for *all* kernels less than the bleeding edge -rc candidate (only supporting them through a backport system for testers). The two are very different things. Yes they are very different things. I do not like a poll about dropping the current build system being disguised as a poll about dropping support for very old kernels. How about a new poll, should developers be required to have multiple systems and spend the majority of their time recompiling new kernels and testing nvidia and wireless drivers? The poll was just about dropping support for old kernels. Nothing more, nothing less. There were a few who commented that they wouldn't mind dropping all compatibility, but those were very much a minority. I for one want to keep the compatibility code in one way or another so we can support the last X kernels and make life easy for ourselves and for our users. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Devin, Please, don't invert the things. I am the one that is trying to defend the need of keeping the backport, while most of you are trying to convince to me to just drop it, since developers will run the bleeding edge -rc. With the argument that developers shouldn't run the bleeding edge kernel, I'd say you should do it. This is the way kernel development is. You shouldn't send something upstream, if your patch doesn't run with the latest -rc. In my case, I have my alpha environment for such tests, separated from the environment I write my code. This allows me to do development on a more stable environment, being sure that it will keep running with the latest kernel. With the respect of using the backported environment for developing, you can do it, if you want. It will be available for all usages. Have you ever seen the approach I'm proposing at my backported tree? I can't see why you couldn't use it for development also. Mauro, When this thread was started, it was about dropping support for kernels 2.6.22. However, it has turned into a thread about moving to git and dropping support for *all* kernels less than the bleeding edge -rc candidate (only supporting them through a backport system for testers). The two are very different things. I agree with the general consensus that we should raise the minimum bar from 2.6.16 to 2.6.22. And I also believe that we need to ensure that we do not want to lose testers by requiring them to run the latest kernel release. However, now we are talking about what the *developers* are expected to run. What has now been proposed is changing the build system such that developers must run the latest -rc kernel, which I do not believe is a good idea. It makes it easier for the maintainer to merge patches, however at the cost of the other developers trying to focus on v4l-dvb development without having to worry about whether this week's -rc kernel is going to work in their environment. It already takes me half an hour to checkout and build the latest v4l-dvb tree. Telling me that now I'm going to have to download and build the entire kernel on a weekly basis, as well as deal with whatever crap gets broken in my environment, is too much for many developers who don't work for a distribution vendor. For a developer working nights and weekends on this stuff, this ends up being a significant fraction of my development time. I just want it to be clear that there are developers who are not willing to run the latest -rc kernel just for the luxury of being able to contribute to v4l-dvb. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Sat, 21 Mar 2009 08:05:51 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Fri, Mar 20, 2009 at 11:04 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Devin, Please, don't invert the things. I am the one that is trying to defend the need of keeping the backport, while most of you are trying to convince to me to just drop it, since developers will run the bleeding edge -rc. With the argument that developers shouldn't run the bleeding edge kernel, I'd say you should do it. This is the way kernel development is. You shouldn't send something upstream, if your patch doesn't run with the latest -rc. In my case, I have my alpha environment for such tests, separated from the environment I write my code. This allows me to do development on a more stable environment, being sure that it will keep running with the latest kernel. With the respect of using the backported environment for developing, you can do it, if you want. It will be available for all usages. Have you ever seen the approach I'm proposing at my backported tree? I can't see why you couldn't use it for development also. Mauro, When this thread was started, it was about dropping support for kernels 2.6.22. However, it has turned into a thread about moving to git and dropping support for *all* kernels less than the bleeding edge -rc candidate (only supporting them through a backport system for testers). The two are very different things. I agree with the general consensus that we should raise the minimum bar from 2.6.16 to 2.6.22. And I also believe that we need to ensure that we do not want to lose testers by requiring them to run the latest kernel release. However, now we are talking about what the *developers* are expected to run. What has now been proposed is changing the build system such that developers must run the latest -rc kernel, which I do not believe is a good idea. It makes it easier for the maintainer to merge patches, however at the cost of the other developers trying to focus on v4l-dvb development without having to worry about whether this week's -rc kernel is going to work in their environment. As I said before, this is not the proper moment for such discussions. People are still focused on the 2.6.30 merge stuff. We should discuss it by the end of the merge window, discussing the newly model to be used starting at the 2.6.31 cycle. It is important to discuss a new model, since the current one has some flaws, like: - bug fixes are sometimes postponed, since they depend on the bleeding edge patches; - our model is different from the rest of Linux kernel community; - it is hard to merge patches that needs coordination with changes outside drivers/media; - the need of conversion for each -hg patch into -git; - the need of backport upstream changes at the building system, and keeping track of such changes. - the increased volume of patches on v4l/dvb made our development model incredible complex for submitting work upstream, since it doesn't scale well, and has caused some hard to solve merge conflicts. From my side, I never proposed to drop the backport system, but to improve it, in a way that people can keep working and testing the subsystem with legacy kernels, although I've seen several comments on this poll where people are arguing to just drop all backports. It already takes me half an hour to checkout and build the latest v4l-dvb tree. Telling me that now I'm going to have to download and build the entire kernel on a weekly basis, as well as deal with whatever crap gets broken in my environment, is too much for many developers who don't work for a distribution vendor. For a developer working nights and weekends on this stuff, this ends up being a significant fraction of my development time. It seems that you're afraid of the unknown. There are several ways to use -git. You can even use a spare git clone, where, for example, only drivers/media will be cloned on your local machine. Since we haven't discussed how a new development model would work, it is pointless to be against something that were not even proposed. And it weren't proposed yet due to the fact that people didn't have time yet to prepare a proposal and test it. Also, due to the need of providing fix packages for linux-next, the current development kernel and the last stable one, this means that any model we use will need to work properly on all those cases. I just want it to be clear that there are developers who are not willing to run the latest -rc kernel just for the luxury of being able to contribute to v4l-dvb. If we review the poll comments, and include some occasional emails about our development model, we'll have all sorts of different opinions: - People that want to keep backports as-is; - People that want to set the baseline to 2.6.22; - People that want to set a higher line (some even proposed to cut it to support
Re: Results of the 'dropping support for kernels 2.6.22' poll
Hans, On Mon, 2 Mar 2009 22:18:24 +0100 Hans Verkuil hverk...@xs4all.nl 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. Pt! 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, 20 Mar 2009 21:47:07 +0100 Hans Werner hwern...@gmx.de wrote: 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. True. Yet, the more easy for end users to have their devices working on their environments, the more number of end tail contributions we'll have, fixing issues on specific devices whose the main developers don't have. 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. Let's first finish 2.6.30 merge window. Then, we'll have more time to cleanup the tree and think on moving to git. Now, everyone is focused on having their work done for the next tree. 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? My suggestion is to keep a backporting system, but more targeted at the end-users. The reasons are the ones explained above. Basically: - Allow end-users to test the drivers without requiring immediate kernel upgrade to the latest -rc-git tree, on their environments; - Offer a tree where people can use to generate contributions like adding new devices at cards table. It should also be clear for all that the backported system is not targeted on offering any kind of implicit or explicit warranty that a driver will work on a legacy kernel. It is a paper of the distros to provide such kind of support. Also, to provide such warranty, other files outside linux/media would need to be patched [1]. So, the backport should keep being provided as a best-effort model, just like what we have right now with all the backports on our tree: we expect it to work, but it may not work on some environments. No warranties are given. I intend to write a proposal about it sometime after the merge window, for people to comment and to contribute with. [1] Just as an example, the USB video drivers leak memory if you're using isoc USB transfers on kernels bellow 2.6.29. So, after some stress conditions, you can eventually run out of memory on legacy kernels. The fix is outside the linux media scope (it is due to a bug at ehci_hcd scheduler). Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: My suggestion is to keep a backporting system, but more targeted at the end-users. The reasons are the ones explained above. Basically: Ok, so just so we're all on the same page - we're telling all the developers not willing to run a bleeding edge rc kernel to screw off? Got an Nvidia video card? Go away! The wireless broken in this week's -rc candidate? Go away! Your distro doesn't yet support the bleeding edge kernel? Go away! Want to have a stable base on which to work so you can focus on v4l-dvb development? Go away! I can tell you quite definitely that you're going to lose some developers with this approach. You better be damn sure that the lives you're making easier are going to significantly outweigh the developers willing to contribute who you are casting aside. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, 20 Mar 2009 22:03:21 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: My suggestion is to keep a backporting system, but more targeted at the end-users. The reasons are the ones explained above. Basically: Ok, so just so we're all on the same page - we're telling all the developers not willing to run a bleeding edge rc kernel to screw off? Got an Nvidia video card? Go away! The wireless broken in this week's -rc candidate? Go away! Your distro doesn't yet support the bleeding edge kernel? Go away! Want to have a stable base on which to work so you can focus on v4l-dvb development? Go away! I can tell you quite definitely that you're going to lose some developers with this approach. You better be damn sure that the lives you're making easier are going to significantly outweigh the developers willing to contribute who you are casting aside. Devin, Please, don't invert the things. I am the one that is trying to defend the need of keeping the backport, while most of you are trying to convince to me to just drop it, since developers will run the bleeding edge -rc. With the argument that developers shouldn't run the bleeding edge kernel, I'd say you should do it. This is the way kernel development is. You shouldn't send something upstream, if your patch doesn't run with the latest -rc. In my case, I have my alpha environment for such tests, separated from the environment I write my code. This allows me to do development on a more stable environment, being sure that it will keep running with the latest kernel. With the respect of using the backported environment for developing, you can do it, if you want. It will be available for all usages. Have you ever seen the approach I'm proposing at my backported tree? I can't see why you couldn't use it for development also. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, 20 Mar 2009, Devin Heitmueller wrote: On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: My suggestion is to keep a backporting system, but more targeted at the end-users. The reasons are the ones explained above. Basically: Ok, so just so we're all on the same page - we're telling all the developers not willing to run a bleeding edge rc kernel to screw off? Got an Nvidia video card? Go away! The wireless broken in this week's -rc candidate? Go away! Your distro doesn't yet support the bleeding edge kernel? Go away! Want to have a stable base on which to work so you can focus on v4l-dvb development? Go away! Maybe you're supposed to have ten computers running different kernels? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Sun, 15 Mar 2009, Hans Verkuil wrote: On Sunday 15 March 2009 17:39:11 Trent Piepho wrote: Because there are patches that touch both the media tree and outside it? I don't buy it. Even for sub-systems that only use full git trees, you almost never see a patch that touches multiple areas of maintainership. It's just too hard to deal with getting acks from everyone involved, dealing with the out-of-sync development git trees of the multiple areas you want to touch, figuring out who will take your patch, etc. Think embedded devices like omap, davinci and other SoC devices. These all require changes in both v4l-dvb and arch at the same time. Easy to do if you have a full git tree, much harder to do in the current situation. These devices will become much more important in the coming months and years, so having a proper git tree will definitely help. This is a relatively new development and before that it was indeed rare to see patches touching on areas outside the media tree. Not anymore, though. ALSA has a full git tree now, so there should be all these patches that touch sound/ and something out side of sound too? I'm not seeing them. The only patches that touch inside and outside of ALSA are the ones that fix some misspelled word in 100 random files or rename a linux header file. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Sun, Mar 15, 2009 at 12:39 PM, Trent Piepho xy...@speakeasy.org wrote: It seems like the real complaint is that dealing v4l-dvb's development system is more work for those people who choose not to use it. Why don't we just switch to CVS while were at it, to make it easier for those who don't want to learn git? Personally, the problem for me is not one of which source control system we use. I don't care if it's cvs, svn, bzr, hg, or git. What I do care about is what the tree contains. I do all of my development on a stock Ubuntu box that is running the latest stable release (Intrepid right now). I want to do v4l-dvb development, but I do *not* want to be required to run the bleeding edge kernel. I want to do v4l-dvb development without having to worry about whether my wireless chipset is going to work today, or my video driver. Having a stable distro allows me to focus on *my* driver without being susceptible to breakage unrelated to my work. I know I'm not the only one who develops with this model. This is not just an issue about the people looking to test the tree. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Saturday 07 March 2009, Trent Piepho wrote: Audio was out of tree. If they had a better system, like v4l-dvb does, they might well still be out of tree. And aren't there some wireless packages that are out of tree? Wireless development is done in tree and then copied to a compat tree that contains just the wireless drivers, stack and compatibility stubs. A year or two back there were some drivers developed out of tree so they could be tested more easily but it became too much of an overhead to work that way. Adam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Thu, 5 Mar 2009, Trent Piepho wrote: ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Right, it was a lot of work, it is still quite a bit of work (well, I'm not doing that work directly, but it affetcs me too, when I have to adjust patches, that I generated from a complete kernel tree to fit compatibility-emhanced versions), and it is not going to be less work. Why must you generate your patches from a different tree? One could just as well say that the linux kernel indentation style is more work, since they use GNU style have to translate their patch from a re-indented tree. You could just make your patches in the v4l-dvb tree and then you wouldn't have the translate them. In fact it could be easier, as you can develop your patches against the kernel you are using now instead of needing to switch to the latest kernel from a few hours ago. I wish I could use the v4l-dvb system for embedded system development in other areas. In my experience most embedded hardware can't run the stock kernel. Most embedded system development is for new systems that don't have all their code in the stock kernel yet. They often have very device specific things that aren't even wanted in the kernel. So you end up needing to do development with an older kernel that works for your device, e.g. the kernel that came with the BSP. In order to submit your patches, you then have to port them to the latest kernel. Not only is that extra work, you now have two patches, one in your device tree and one in your kernel.org tree. If you fix one patch you have to manually keep the other in sync. The v4l-dvb is much better as you can have just _one_ patch that works on _both_ kernels. Lots of subsystems are more tightly connected to the kernel and compiling the subsystem out of tree against any kernel just wouldn't work. Some subsystems (like say gpio or led) mostly provide a framework to the rest of the kernel so working on them without the rest of the tree doesn't make sense either. Or they don't get many patches and don't have many active maintainers so they don't really have any development SCM at all. Just some patches through email that get applied by one maintainer. That's why I didn't give LED or GPIO or SPI or I2C or SCSI or ATA or MMC or MTD or ... as examples, but audio and network, which are also largely consumer interfaces and are actively developed. Audio was out of tree. If they had a better system, like v4l-dvb does, they might well still be out of tree. And aren't there some wireless packages that are out of tree? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Fri, 6 Mar 2009, Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Thu, 5 Mar 2009, Trent Piepho wrote: ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Right, it was a lot of work, it is still quite a bit of work (well, I'm not doing that work directly, but it affetcs me too, when I have to adjust patches, that I generated from a complete kernel tree to fit compatibility-emhanced versions), and it is not going to be less work. Why must you generate your patches from a different tree? One could just as well say that the linux kernel indentation style is more work, since they use GNU style have to translate their patch from a re-indented tree. [snip] Hans has already answered your question very well in this thread. I don't think I can add anything. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
Hi, Am Samstag, den 07.03.2009, 01:46 +0100 schrieb Guennadi Liakhovetski: On Fri, 6 Mar 2009, Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Thu, 5 Mar 2009, Trent Piepho wrote: ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Right, it was a lot of work, it is still quite a bit of work (well, I'm not doing that work directly, but it affetcs me too, when I have to adjust patches, that I generated from a complete kernel tree to fit compatibility-emhanced versions), and it is not going to be less work. Why must you generate your patches from a different tree? One could just as well say that the linux kernel indentation style is more work, since they use GNU style have to translate their patch from a re-indented tree. [snip] Hans has already answered your question very well in this thread. I don't think I can add anything. Thanks Guennadi for me Trent clearly has the better arguments, but I do have of course a different point of view. Let's have this embedded Linux conference and listen to the arguments we hopefully get some links to. There is a lot going on, but you must convince me at least to buy some of this stuff I call gadgets. I don't see any need so far ;) You likely can get still anybody seriously interested to build the always next rc1 and then one close to the final next kernel release too, but I seriously doubt that you can convince anybody at all to give up totally what we have for embedded mixed trees fun on latest git and break all others by will for your latest pleasure. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote: 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. 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. Sorry, switching to git is great, but just to make sure I understood you right: by -git drivers/media you don't mean it is going to be a git tree of only drivers/media, but it is going to be a normal complete Linux kernel tree, right? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Thursday 05 March 2009 21:57:16 Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Thu, 5 Mar 2009, Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote: 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. 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. Sorry, switching to git is great, but just to make sure I understood you right: by -git drivers/media you don't mean it is going to be a git tree of only drivers/media, but it is going to be a normal complete Linux kernel tree, right? So there will be no way we can test a driver without switching to a new kernel hourly? And there is no way we can test someone else's tree without compiling an entirely new kernel and rebooting? And every tree we want to work on requires a complete copy of the entire kernel source? AFAIR, Mauro wanted to provide snapshots for those who absolutely prefer to work with partial trees. Although, to be honest, I don't understand what makes video drivers so special. Think about audio drivers, or network, including WLAN. I never heard about those subsystems working with or providing subtree snapshots. If only before specific drivers or subsystems are included in the mainline, but not long after that. ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Lots of subsystems are more tightly connected to the kernel and compiling the subsystem out of tree against any kernel just wouldn't work. Some subsystems (like say gpio or led) mostly provide a framework to the rest of the kernel so working on them without the rest of the tree doesn't make sense either. Or they don't get many patches and don't have many active maintainers so they don't really have any development SCM at all. Just some patches through email that get applied by one maintainer. Our model of just the subsystem is fine when all you are dealing with are PCI and USB devices, but especially with embedded devices you get a lot of links to the platform code. For that you need to have a full kernel. I expect that the embedded drivers will be a very active area for the next several years so we have to make sure we can handle that. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Thu, 5 Mar 2009, Trent Piepho wrote: ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Right, it was a lot of work, it is still quite a bit of work (well, I'm not doing that work directly, but it affetcs me too, when I have to adjust patches, that I generated from a complete kernel tree to fit compatibility-emhanced versions), and it is not going to be less work. Lots of subsystems are more tightly connected to the kernel and compiling the subsystem out of tree against any kernel just wouldn't work. Some subsystems (like say gpio or led) mostly provide a framework to the rest of the kernel so working on them without the rest of the tree doesn't make sense either. Or they don't get many patches and don't have many active maintainers so they don't really have any development SCM at all. Just some patches through email that get applied by one maintainer. That's why I didn't give LED or GPIO or SPI or I2C or SCSI or ATA or MMC or MTD or ... as examples, but audio and network, which are also largely consumer interfaces and are actively developed. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
Hans, On Mon, 2 Mar 2009 22:18:24 +0100 Hans Verkuil hverk...@xs4all.nl 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. 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. 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 -- PS: the tea6415c.c fully ported to the new I2C API you sent in priv doesn't compile fine with 2.6.28. Since this file is just an example, I didn't care to fix it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Tue, 3 Mar 2009, Hans Verkuil wrote: On Monday 02 March 2009 23:47:31 Trent Piepho wrote: On Mon, 2 Mar 2009, Hans Verkuil wrote: There are good reasons as a developer for keeping backwards compatibility with older kernels: Do you mean no backwards compatibility with any older kernels? Or do you mean just dropping support for the oldest kernels now supported. What you've said above sounds like the former. This was about the advantages of having compat code at all to support kernels other than the bleeding edge git kernel. I thought the poll was only about dropping support for kernels older than 2.6.22? Will you allow drivers to use a combination of probe based and detect based i2c using the new i2c api? It's my understanding that you only support the new i2c api for probe-only drivers. Probe/detect or ever detect-only drivers for the new i2c api haven't been done? I think much of the difficulty of supporting 2.6.22 will be solved once there is a way to allow drivers to use both probe and detect with the new api. The difficulties are not with probe or detect, but with the fact that with the new API the adapter driver has to initiate the probe instead of the autoprobing that happened in the past by just loading the i2c module. The That's not true. Using the new API's -probe() method works like you say, but using the new API's -detect() method is much more like the autoprobing that happened in the past. I don't think we have to use the detect() functionality at all in i2c modules, although I need to look at bttv more closely to see whether that is a true statement. I'm at this moment opposed to the use of detect() since I fear it can lead to pretty much the same problems as autoprobing does when you start to rely on it. It's meant for legacy code where proper device/address information is not present. In the case of v4l-dvb the only driver that might qualify is bttv. In some cases there is no way to identify the what hardware a card has and there is also new cards that are still unknown. I think I would have gone about it from the other side. Convert bttv to use detect and then make that backward compatible. That compatibility should be much easier and less invasive. This wouldn't have made any difference at all. But you said yourself that the difficulties are with the fact that with the new API the adapter driver has to initiate the probe instead of the autoprobing that happened in the past. Converting the bttv driver to use detect with the new API would avoid those difficulties. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Mon, 2 Mar 2009, Hans Verkuil wrote: snip [...] The one argument I've seen that I thought had merit was with regards to netbooks, and the Asus eeePC in particular. Apparently that distro uses 2.6.21 and whether that will be upgraded to a newer kernel in the future is dubious. But in the end it is really the same story: where do you put the line? If the eeePC will never receive an update, does that mean we have to keep maintaining support for 2.6.21 for many years to come? That's ridiculous IMHO. Hans, Just one comment. IIRC, I was the one who mentioned the eeePC, having recently bought one. I mentioned it, not because I disagree with anything else you write here, but because, in fact, I agree. Frankly, I think the use of the 2.6.21 kernel in the eeePC is somewhat perverse and just a little bit weird. Essentially, the eeePC and the other Intel-based netbooks are not some kind of exotic hardware platforms, which might provide an explanation or excuse for using some specially crafted but old kernel. No. In fact, the eeePC and almost all the other current netbooks are just a new (and attractive) combination of some fairly standard types of hardware. Practically every hardware component in them is better supported in more recent kernels, with the possible exception of a wireless device which may not yet be supported in any kernel, new or old. Therefore, instead of worrying about whether to support and provide indulgence for apparently inexplicable behavior, let us hope that a decision of this nature will serve as a needed message. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Mon, 2 Mar 2009, Hans Verkuil wrote: There are good reasons as a developer for keeping backwards compatibility with older kernels: Do you mean no backwards compatibility with any older kernels? Or do you mean just dropping support for the oldest kernels now supported. What you've said above sounds like the former. 1) a larger testers base. 2) that warm feeling you get when users can get their new card to work with just v4l-dvb without having to upgrade their kernel. 3) as a developer you do not need to update to the latest kernel as well. Very useful if the latest kernel introduces a regression on your hardware as happened to me in the past. It's also very useful for working on/testing multiple trees. I can test your zoran tree, switch to a different tree for some cx88 work, and then switch back to a know good tree to record some tv shows tonight. I can switch back and forth between your zoran tree and a months older one in *seconds* to check differences in behavior. Without having to reboot two dozen times a day to a half dozen different kernels. For the most part the v4l-dvb compat system works behind the scenes very well. I'm sure there have been cases where a developer who doesn't reboot hourly to the latest git kernel produced a patch that wouldn't have worked on the kernel they were themselves using if the compat system hadn't made it work automatically without the developer even knowing. 2) as time goes by the code becomes ever harder to maintain due to the accumulated kernel checks. Unless you want to maintain backwards compat forever, the idea is to reach some kind of equilibrium were old compat code is removed at the same rate new compat code is added. 3) the additional complication of backwards compatibility code might deter new developers. But needing to run today's kernel and have your closed source video card driver stop working might deter developers who just want to produce a few small patches. There has to be a balance here. Currently it is my opinion that I'm spending too much time on the backwards compat stuff. And that once all the i2c modules are converted to the new framework both the maintainability and the effort required to maintain the compat code will be improved considerably by dropping support for kernels 2.6.22. Will you allow drivers to use a combination of probe based and detect based i2c using the new i2c api? It's my understanding that you only support the new i2c api for probe-only drivers. Probe/detect or ever detect-only drivers for the new i2c api haven't been done? I think much of the difficulty of supporting 2.6.22 will be solved once there is a way to allow drivers to use both probe and detect with the new api. I think I would have gone about it from the other side. Convert bttv to use detect and then make that backward compatible. That compatibility should be much easier and less invasive. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
kilg...@banach.math.auburn.edu wrote: Just one comment. IIRC, I was the one who mentioned the eeePC, having recently bought one. I mentioned it, not because I disagree with anything else you write here, but because, in fact, I agree. Frankly, I think the use of the 2.6.21 kernel in the eeePC is somewhat perverse and just a little bit weird. Essentially, the eeePC and the other Intel-based netbooks are not some kind of exotic hardware platforms, which might provide an explanation or excuse for using some specially crafted but old kernel. No. In fact, the eeePC and almost all the other current netbooks are just a new (and attractive) combination of some fairly standard types of hardware. Practically every hardware component in them is better supported in more recent kernels, with the possible exception of a wireless device which may not yet be supported in any kernel, new or old. Therefore, instead of worrying about whether to support and provide indulgence for apparently inexplicable behavior, let us hope that a decision of this nature will serve as a needed message. just as another data point i have an eee 900 and i run gentoo on it i have 2.6.27 running just fine (wireless and all) i know gentoo is a little too hardcore for most people but living with a distro kernel forever is not a real requirement -- simon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Monday 02 March 2009 23:47:31 Trent Piepho wrote: On Mon, 2 Mar 2009, Hans Verkuil wrote: There are good reasons as a developer for keeping backwards compatibility with older kernels: Do you mean no backwards compatibility with any older kernels? Or do you mean just dropping support for the oldest kernels now supported. What you've said above sounds like the former. This was about the advantages of having compat code at all to support kernels other than the bleeding edge git kernel. 1) a larger testers base. 2) that warm feeling you get when users can get their new card to work with just v4l-dvb without having to upgrade their kernel. 3) as a developer you do not need to update to the latest kernel as well. Very useful if the latest kernel introduces a regression on your hardware as happened to me in the past. It's also very useful for working on/testing multiple trees. I can test your zoran tree, switch to a different tree for some cx88 work, and then switch back to a know good tree to record some tv shows tonight. I can switch back and forth between your zoran tree and a months older one in *seconds* to check differences in behavior. Without having to reboot two dozen times a day to a half dozen different kernels. For the most part the v4l-dvb compat system works behind the scenes very well. I'm sure there have been cases where a developer who doesn't reboot hourly to the latest git kernel produced a patch that wouldn't have worked on the kernel they were themselves using if the compat system hadn't made it work automatically without the developer even knowing. 2) as time goes by the code becomes ever harder to maintain due to the accumulated kernel checks. Unless you want to maintain backwards compat forever, the idea is to reach some kind of equilibrium were old compat code is removed at the same rate new compat code is added. Right. 3) the additional complication of backwards compatibility code might deter new developers. But needing to run today's kernel and have your closed source video card driver stop working might deter developers who just want to produce a few small patches. There has to be a balance here. Currently it is my opinion that I'm spending too much time on the backwards compat stuff. And that once all the i2c modules are converted to the new framework both the maintainability and the effort required to maintain the compat code will be improved considerably by dropping support for kernels 2.6.22. Will you allow drivers to use a combination of probe based and detect based i2c using the new i2c api? It's my understanding that you only support the new i2c api for probe-only drivers. Probe/detect or ever detect-only drivers for the new i2c api haven't been done? I think much of the difficulty of supporting 2.6.22 will be solved once there is a way to allow drivers to use both probe and detect with the new api. The difficulties are not with probe or detect, but with the fact that with the new API the adapter driver has to initiate the probe instead of the autoprobing that happened in the past by just loading the i2c module. The compat issues are for the most part limited to the i2c modules themselves, since those changed the most because of this. I don't think we have to use the detect() functionality at all in i2c modules, although I need to look at bttv more closely to see whether that is a true statement. I'm at this moment opposed to the use of detect() since I fear it can lead to pretty much the same problems as autoprobing does when you start to rely on it. It's meant for legacy code where proper device/address information is not present. In the case of v4l-dvb the only driver that might qualify is bttv. I think I would have gone about it from the other side. Convert bttv to use detect and then make that backward compatible. That compatibility should be much easier and less invasive. This wouldn't have made any difference at all. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
