Hello, I don't want to argue if something is new or old. This depends on the point of view, but I'm asking you to revise your considerations of what YOU label as old and I agree with Anand, because this is also my point of view. For my workstation that has dual core cpu and enough ram I can afford it installing and patching almost everyday a new kernel, but what I'm missing is a kind of kernel version that has been debugged and improved (tested) and can be installed on our home/office servers. That is definitely not the case with 2.6.24, that I've been testing for the few last months What happens now is that many things are changing so fixing a bug in a new kernel release may solve the problem related to this bug, but this same kernel comes with couple of other bugs that make the same kernel obsolete especially in embedded environment like Anand says. So I think it's better to get bugs in one kernel version sorted out and then proceed to the next ... and also you should not do major changes in subversion ... the pitty thing is that 2.6.X has many features and advantages compared to 2.4 and I would stick to 2.4. if I was not that lazy to compile all the stuff myself, but may be that's what I should do to avoid further discussions of the kind. I think everything is getting pretty messy recently - I was pretty satisfied with 2.6.20 and then tried 2.6.24. In fact I can not compile 2.6.20 right now because after an upgrade debian testing comes with gcc-4.3 that has a background struggle about who's wrong between gcc people and Linus Torvalds and the issue is still open. So what I'm pleading for is to focus on stability! And yes I'm planing to try 2.6.26, but I'm pretty sure that there would be issues with drivers like uvcview, the proprietary ATI and NVidia and apps like skype So what I would like to have if you "recommend" something than also to provide the functionality expected namely in terms of not only a working kernel but also supported 3rd party drivers and apps and the ability for the developers of such software to catch up thanks for understanding and support --- On Wed, 7/30/08, Gadiyar, Anand <gadiyar@xxxxxx> wrote: > From: Gadiyar, Anand <gadiyar@xxxxxx> > Subject: RE: USB driver issue > To: "felipe.balbi@xxxxxxxxx" <felipe.balbi@xxxxxxxxx>, "ext Emanoil Kotsev" <deloptes@xxxxxxxxx> > Cc: "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx>, "linux-omap-open-source@xxxxxxxxxxxxxx" <linux-omap-open-source@xxxxxxxxxxxxxx>, "SUBHRANIL CHOUDHURY" <subhra85@xxxxxxxxx>, "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx> > Date: Wednesday, July 30, 2008, 6:23 PM > > On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil > Kotsev wrote: > > > > > > Dear Felipe, I just want to tell, that while > still developing kernels in the 2.6.2X > > series a kernel 2.6.22 can not be labeled as old. > Besides it comes along with few > > distros as default kernel. > > > > > > A lot of people like me need some kind of a > stable version that we can relay on > > > for more than playing at home, which is the case > with 2.4.X tree. > > > > > > Personally, experiments with 2.6.24 brought me > into a big trouble and it took > > > many hours to migrate back to 2.6.20, so please > keep in mind that if we say > > > something like this, there is a good reason to do > so. > > > > You can always choose any kernel version you want but > if you choose such > > an old version (2.6.22 was released in Jul 8th, 2007), > please don't rely > > in community support and instead, backport all changes > in the particular > > driver you're working with to 2.6.22. > > > > It's always your choice. > > That's plain wrong. 2.6.22 was released in July 2007. > But 2.6.22.18 was not. > That came much later - in February this year. And people > still do use 2.6.22 > kernels. Besides, the MUSB code hasn't really changed > that much in this time. > > Do you really think the problem will go away in 2.6.26? > People can't always use the > latest kernel, you know. Embedded kernels don't get > enough testing. There's always > a chance this is a new driver. And even if it weren't, > the very act of debugging > a problem like this is a good learning experience. > > Grr. Saying one needs to upgrade to the latest kernel > before one can expect > support is a bit like certain proprietary OS vendors - and > even they do a better > job than this. > > Regards, > Anand > -- > To unsubscribe from this list: send the line > "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
