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. >> 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. > 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. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
