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

[Bruce Ashfield]

On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Tue, 2012-12-11 at 05:52 -0500, Bruce Ashfield wrote:
> > On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz
> > <marcin.juszkiewicz at linaro.org> wrote:
> >         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.
> >
> > There aren't any plans to use 3.7 for the headers, since we are
> > tracking the headers
> > with the same cadence as the yocto release kernels. Otherwise, we'd
> > really need
> > to have all versions available, and keeping things clean and focussed
> > was the
> > goal.
> >
> > 3.8 is the next likely update.
> >
> > That being said,  since the libc-headers version is controlled by the
> > LINUXLIBCVERSION in tcmode-default.inc, simply having 3.7 headers
> > available shouldn't cause any problems or disconnects.
> >
> > So we can open up the discussion if we want to carry extra libc
> > headers or
> > keep with the current strategy. I've added Richard explicitly to the
> > cc' so he
> > can jump in as appropriate.
> >
> 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.


>
> 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.

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 ?

Cheers,

Bruce


>
> Cheers,
>
> Richard
>
>
>
>


-- 
"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/055797b0/attachment-0002.html>