<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 2012-12-11 at 05:52 -0500, Bruce Ashfield wrote:<br>
> On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz<br>
> <<a href="mailto:marcin.juszkiewicz@linaro.org">marcin.juszkiewicz@linaro.org</a>> wrote:<br>
> I would like to know are there plans to use 3.7 kernel for<br>
> libc headers.<br>
> This will allow me to drop own copy which I need to keep due<br>
> to AArch64<br>
> stuff which got added in 3.7 cycle.<br>
><br>
> There aren't any plans to use 3.7 for the headers, since we are<br>
> tracking the headers<br>
> with the same cadence as the yocto release kernels. Otherwise, we'd<br>
> really need<br>
> to have all versions available, and keeping things clean and focussed<br>
> was the<br>
> goal.<br>
><br>
> 3.8 is the next likely update.<br>
><br>
> That being said, since the libc-headers version is controlled by the<br>
> LINUXLIBCVERSION in tcmode-default.inc, simply having 3.7 headers<br>
> available shouldn't cause any problems or disconnects.<br>
><br>
> So we can open up the discussion if we want to carry extra libc<br>
> headers or<br>
> keep with the current strategy. I've added Richard explicitly to the<br>
> cc' so he<br>
> can jump in as appropriate.<br>
><br>
</div>As I understand things we agreed that we'd not bump for point releases<br>
on the headers unless there was some pressing reason too. The rest of<br>
the policy for kernel headers is a bit more fuzzy.<br>
<br>
For actual major version increments like this, I'm tempted to accept<br>
that in this case we have a good argument for updating to 3.7 and even<br>
though the linux-yocto kernels will lag behind this for a (short) while,<br>
it shouldn't make any real world difference to anything, certainly not<br>
cause breakage.<br></blockquote><div><br></div><div>Right, they'll lag, but then jump and increment it to 3.8+. The dev kernel</div><div>is already on 3.7 and currently building and working fine against the 3.4.x</div>
<div>libc-headers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There isn't any technical reason we have to keep in lockstep, or any<br>
known issues with doing that with these versions, right? I know you have<br>
been burnt in the past but that was quite a while ago and the<br>
kernel/toolchain communities have moved to address that?<br></blockquote><div><br></div><div>I've definitely been burt in the past, I admit to being a little nervous about</div><div>3.7 sideffects due to the uapi split in the kernel .. and right around </div>
<div>the Holidays, I'm a bit more paranoid about bringing this in. I'd rather be</div><div>full time at my keyboard, just in case something subtle breaks.</div><div><br></div><div>If we bring this in, I'd prefer to completely drop the 3.4 kernel headers, since</div>
<div>having just one recipe in the tree make sense, and it won't tempt us to</div><div>start having a trail of one libc-header per kernel version (since there's always</div><div>a layer somewhere that's using a given version).</div>
<div><br></div><div>What about a middle ground ? I can pull this into my tree, since I'm doing</div><div>some 3.8 and 3.4-stable work at the moment, I'll remove the 3.4 kernel</div><div>headers and then submit it again as part of my queue with some extra</div>
<div>tests run ?</div><div><br></div><div>Cheers,</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"<br>
</div>