Le 01/08/2012 16:51, Weedy a écrit : > On 01/08/12 04:57 AM, Emmanuel Deloget wrote: >> Hello, >> >> I understand that a lot of effort has been pushed in making >> Linux 3.3 the trunk kernel, and I understand that I probably >> missed long (IRC?) discussions on this very subject, but since >> 3.3.8 is going to be the last supported kernel in the 3.3.x >> branch it might be a good idea to move on to another, more >> recent kernel version - and to do it slightly better. Not >> that anything is really bad, but there were obviously better >> choices that 3.3 at the time it came up. > > 3.3 was probably chosen based on wifi driver quality at the time. I > think we started with 3.3.2 or .3 so it was pretty new at the time. > Because of that we (most probably) can't drop down to 3.0.
I agree that 3.0 lacked a lot of changes made to support wifi and other interesting features. This makes my remarks about the existence of better choices a bit weird (but then, note that 3.4 was well in the way when 3.3.2 and .3 were released ; according to the tag log on kernel.org, 3.3.2 and 3.4-rc3 were released the same week ; that doesn't make 3.4 a better choice, since it has yet to be released). Even if 3.4 was not option, and that (in fact, and contrary to my precendent assertions) 3.3 was a good pick, it would have been a good thing to switch to 3.4 as soon as it hit the schelves. I agree and I fully understand that changing a kernel is not a trivial task - it's indeed one of the trickier and probably as risky as changing the compiler or the runtime. I understand that there are many, many things to test and that tests take a lot of time and energy - and time is not free. But IMHO, the migration task should have started as soon as possible. Waiting for kernel patches to accumulate just makes things harder and harder. > Trying to sync with a -rt kernel does seem like a good idea, Yep. I may have some ideas on how to put things together in order to import -rt support in OpenWRT in a sensible way, but this cannot be tested if there is no support for a -rt compatible kernel in the first place. > -longterm seems unnecessary. With products that are out for 4 to 6 years and that target a large, consumer market (I'm talking about millions of units), knowing that the selected kernel will be community-supported for at least 2 years (and maybe more if another maintainer takes the lead) is a huge, huge incentive to invest time and money in this specific kernel. That's the raison d'être of -longterm after all :) Anyway, the lack of support for at least one -longterm (the latest) is still an annoying issue. It makes captilizing on these kernels a problematic issue (and such capitalization is of utter most importance for those who sell routers for a living). OpenWRT is used in professionnal products, and some of these products have a huge install base that needs to be updated from time to time. > For the record my production networks runs trunk (something around > 31xxx, I forget right now). It's a VPN mesh consisting of over 100 nodes > and minutes of downtime is measured in thousands of dollars. Ignoring > the whole "REAL MEN USE TRUNK(tm)" the tagged releases are just too old > to do anything fun with. Doing fun things and making things work are orthogonal notions :) Doing fun things (I guess you are speaking of taking advantages of new features) may even be counter productive (ISP tends to prefer having a working router than one which is able to do fun things :)) <--> Le 01/08/2012 20:40, Hartmut Knaack a écrit :> Hi, > my impression is, that a kernel version makes it into trunk > if it is either a long term kernel, or it brings essential > new functions. For 3.3 this was most certainly the introduction > of BQL code. Keeping in mind that our main targets are network > routers, the bufferbloat issue probably concerns most of the > maintainers. This, along with the information provided by Weedy in his answer, recoup an informal discussion I had with colleagues of mine shortly after I hit the "send" button. My orginal mail contains a bit of noise and some misinformed statements, but the idea was never to derail the choices that were made a few month ago. Its goal was more to discuss the choice of *future* kernels, how they will be selected, and objective criterion might be used to select them. I fully apology if the meaning of my fist mail was not clear enough and I hope that this short paragraph clarifies my discourse. Best regards, -- Emmanuel Deloget _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
