On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz < [email protected]> wrote:
> W dniu 18.12.2012 14:32, Bruce Ashfield pisze: > > On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, 2012-12-11 at > >> 05:52 -0500, Bruce Ashfield wrote: > >>> On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz > > >>> I would like to know are there plans to use 3.7 kernel for libc > >>> headers. This will allow me to drop own copy which I need to keep > >>> due to AArch64 stuff which got added in 3.7 cycle. > > >> As I understand things we agreed that we'd not bump for point > >> releases on the headers unless there was some pressing reason too. > >> The rest of the policy for kernel headers is a bit more fuzzy. > >> > >> For actual major version increments like this, I'm tempted to accept > >> that in this case we have a good argument for updating to 3.7 and > >> even though the linux-yocto kernels will lag behind this for a > >> (short) while, it shouldn't make any real world difference to > >> anything, certainly not cause breakage. > > > Right, they'll lag, but then jump and increment it to 3.8+. The dev > > kernel is already on 3.7 and currently building and working fine > > against the 3.4.x libc-headers. > > I need 3.7 for AArch64 as this is first version which has support for it. > Yep, I didn't mean to imply that 3.4 would work for your needs as well, sorry if it came across that way. I assume 3.8+ will be ok for your case as well, since when we jump to the 1.4 kernel, the standing plan of purging all the headers and go back to a single version that matches that kver was going to kick in. I don't want to break your builds. > > >> There isn't any technical reason we have to keep in lockstep, or any > >> known issues with doing that with these versions, right? I know you > >> have been burnt in the past but that was quite a while ago and the > >> kernel/toolchain communities have moved to address that? > > > I've definitely been burt in the past, I admit to being a little > > nervous about 3.7 sideffects due to the uapi split in the kernel .. > > and right around the Holidays, I'm a bit more paranoid about bringing > > this in. I'd rather be full time at my keyboard, just in case > > something subtle breaks. > > Remember that even when l-l-h 3.7 will be present in repo 3.4 can be > still used as default one. > Absolutely. We are just trying to keep things small and clean and avoid having multiple options and then using defaults/preferences to pick .. unless required. We can always pretend things are simple and clean :) > > > If we bring this in, I'd prefer to completely drop the 3.4 kernel > > headers, since having just one recipe in the tree make sense, and it > > won't tempt us to start having a trail of one libc-header per kernel > > version (since there's always a layer somewhere that's using a given > > version). > > > What about a middle ground ? I can pull this into my tree, since I'm > > doing some 3.8 and 3.4-stable work at the moment, I'll remove the 3.4 > > kernel headers and then submit it again as part of my queue with some > > extra tests run ? > > I am fine with it. > Thanks, I'll pull this in if Richard agrees. Cheers, Bruce -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
