All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches,
	discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Add 3.7 version of linux-libc-headers
Date: Tue, 18 Dec 2012 11:07:19 +0000	[thread overview]
Message-ID: <1355828839.18874.8.camel@ted> (raw)
In-Reply-To: <CADkTA4NLkvWThY4fzqzqDc5FO+U+CMJGEjOD9oJsLXDidfoapg@mail.gmail.com>

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

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?

Cheers,

Richard






  reply	other threads:[~2012-12-18 11:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 10:12 Add 3.7 version of linux-libc-headers Marcin Juszkiewicz
2012-12-11 10:12 ` [PATCH] linux-libc-headers: add 3.7 version Marcin Juszkiewicz
2012-12-11 10:52 ` Add 3.7 version of linux-libc-headers Bruce Ashfield
2012-12-18 11:07   ` Richard Purdie [this message]
2012-12-18 13:32     ` Bruce Ashfield
2012-12-18 13:41       ` Marcin Juszkiewicz
2012-12-18 13:56         ` Bruce Ashfield
2012-12-18 17:32           ` Richard Purdie
2013-01-03 21:14             ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1355828839.18874.8.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.