[OE-core] Add 3.7 version of linux-libc-headers

[Bruce Ashfield]

On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz <
marcin.juszkiewicz at linaro.org> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121218/ec941d82/attachment-0002.html>