<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz <span dir="ltr"><<a href="mailto:marcin.juszkiewicz@linaro.org" target="_blank">marcin.juszkiewicz@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">W dniu 18.12.2012 14:32, Bruce Ashfield pisze:<br>
> On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, 2012-12-11 at<br>
<div class="im">>> 05:52 -0500, Bruce Ashfield wrote:<br>
>>> On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz<br>
<br>
</div><div class="im">>>> I would like to know are there plans to use 3.7 kernel for libc<br>
>>> headers. This will allow me to drop own copy which I need to keep<br>
>>> due to AArch64 stuff which got added in 3.7 cycle.<br>
<br>
</div><div class="im">>> As I understand things we agreed that we'd not bump for point<br>
>> releases on the headers unless there was some pressing reason too.<br>
>> The rest of 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<br>
>> even though the linux-yocto kernels will lag behind this for a<br>
>> (short) while, it shouldn't make any real world difference to<br>
>> anything, certainly not cause breakage.<br>
<br>
> Right, they'll lag, but then jump and increment it to 3.8+. The dev<br>
> kernel is already on 3.7 and currently building and working fine<br>
> against the 3.4.x libc-headers.<br>
<br>
</div>I need 3.7 for AArch64 as this is first version which has support for it.<br></blockquote><div><br></div><div>Yep, I didn't mean to imply that 3.4 would work for your needs as well, sorry</div><div>if it came across that way.</div>
<div><br></div><div>I assume 3.8+ will be ok for your case as well, since when we jump to the</div><div>1.4 kernel, the standing plan of purging all the headers and go back to a</div><div>single version that matches that kver was going to kick in. I don't want to </div>
<div>break your builds.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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<br>
>> have been burnt in the past but that was quite a while ago and the<br>
>> kernel/toolchain communities have moved to address that?<br>
<br>
> I've definitely been burt in the past, I admit to being a little<br>
> nervous about 3.7 sideffects due to the uapi split in the kernel ..<br>
> and right around the Holidays, I'm a bit more paranoid about bringing<br>
> this in. I'd rather be full time at my keyboard, just in case<br>
> something subtle breaks.<br>
<br>
</div>Remember that even when l-l-h 3.7 will be present in repo 3.4 can be<br>
still used as default one.<br></blockquote><div><br></div><div>Absolutely. We are just trying to keep things small and clean and avoid</div><div>having multiple options and then using defaults/preferences to pick .. unless</div>
<div>required. We can always pretend things are simple and clean :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> If we bring this in, I'd prefer to completely drop the 3.4 kernel<br>
> headers, since having just one recipe in the tree make sense, and it<br>
> won't tempt us to start having a trail of one libc-header per kernel<br>
> version (since there's always a layer somewhere that's using a given<br>
> version).<br>
<br>
> What about a middle ground ? I can pull this into my tree, since I'm<br>
> doing some 3.8 and 3.4-stable work at the moment, I'll remove the 3.4<br>
> kernel headers and then submit it again as part of my queue with some<br>
> extra tests run ?<br>
<br>
</div>I am fine with it.<br>
</blockquote></div><br>Thanks, I'll pull this in if Richard agrees.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Bruce<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>