Patchwork [4/5] libc-headers: set TC default to 3.14

login
register
mail settings
Submitter Bruce Ashfield
Date March 31, 2014, 5:56 p.m.
Message ID <e6015802086cbf8199d112a3e75a7391a417ede6.1396288310.git.bruce.ashfield@windriver.com>
Download mbox | patch
Permalink /patch/69747/
State New
Headers show

Comments

Bruce Ashfield - March 31, 2014, 5:56 p.m.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Khem Raj - March 31, 2014, 7:29 p.m.
On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
>
> -LINUXLIBCVERSION ?= "3.10"
> +LINUXLIBCVERSION ?= "3.14"

Does this  buy us much ? Infact its too late to change usespace APIs
at this point. 3.10 being LTS
I would assume its a better option to keep at 3.10
Bruce Ashfield - March 31, 2014, 7:33 p.m.
On 14-03-31 03:29 PM, Khem Raj wrote:
> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>>
>> -LINUXLIBCVERSION ?= "3.10"
>> +LINUXLIBCVERSION ?= "3.14"
>
> Does this  buy us much ? Infact its too late to change usespace APIs

This was always the plan. I've been building with all the 3.14 -rc
headers for ages .. and as we've talked about in the past, we always
will update them to the newest kernel in any release.

They are compatible with 3.10, and I've tested the combinations of
old kernels, new libc and new kernels with the new libc interfaces.

> at this point. 3.10 being LTS
> I would assume its a better option to keep at 3.10

I disagree, this is consistent with other releases and the documented
plan of action. I'd rather not have a massive version jump in the fall.

Sure 3.14 slipping out by a few weeks upstream was a problem, but its
not like we haven't been testing with it.

Bruce

>
Khem Raj - March 31, 2014, 7:47 p.m.
-Khem
On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <bruce.ashfield@windriver.com>
wrote:
>
> On 14-03-31 03:29 PM, Khem Raj wrote:
>>
>> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
>> <bruce.ashfield@windriver.com> wrote:
>>>
>>>
>>> -LINUXLIBCVERSION ?= "3.10"
>>> +LINUXLIBCVERSION ?= "3.14"
>>
>>
>> Does this  buy us much ? Infact its too late to change usespace APIs
>
>
> This was always the plan. I've been building with all the 3.14 -rc
> headers for ages .. and as we've talked about in the past, we always
> will update them to the newest kernel in any release.

well i think its good to update them however may be some components should
be given enough soak time and kernel headers are one of such pieces since
its effects are across layers and they will start testing them now.
>
> They are compatible with 3.10, and I've tested the combinations of
> old kernels, new libc and new kernels with the new libc interfaces.

i dont believe you tested all layer combinations
>
>
>> at this point. 3.10 being LTS
>> I would assume its a better option to keep at 3.10
>
>
> I disagree, this is consistent with other releases and the documented
> plan of action. I'd rather not have a massive version jump in the fall.

its probably not a bad option to stick to LTS version for kernel headers
after all
>
> Sure 3.14 slipping out by a few weeks upstream was a problem, but its
> not like we haven't been testing with it.
>
> Bruce
>
>>
>
Bruce Ashfield - March 31, 2014, 7:50 p.m.
On 14-03-31 03:47 PM, Khem Raj wrote:
> -Khem
> On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <bruce.ashfield@windriver.com
> <mailto:bruce.ashfield@windriver.com>> wrote:
>  >
>  > On 14-03-31 03:29 PM, Khem Raj wrote:
>  >>
>  >> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
>  >> <bruce.ashfield@windriver.com <mailto:bruce.ashfield@windriver.com>>
> wrote:
>  >>>
>  >>>
>  >>> -LINUXLIBCVERSION ?= "3.10"
>  >>> +LINUXLIBCVERSION ?= "3.14"
>  >>
>  >>
>  >> Does this  buy us much ? Infact its too late to change usespace APIs
>  >
>  >
>  > This was always the plan. I've been building with all the 3.14 -rc
>  > headers for ages .. and as we've talked about in the past, we always
>  > will update them to the newest kernel in any release.
>
> well i think its good to update them however may be some components
> should be given enough soak time and kernel headers are one of such
> pieces since its effects are across layers and they will start testing
> them now.

To be fair, we've had the -dev kernel and headers available for
over a month now.

This is also my second send of this series, so it isn't like this
hasn't been available or broadcast.

People noticing it now, or being busy, isn't something I can directly
control.

>  >
>  > They are compatible with 3.10, and I've tested the combinations of
>  > old kernels, new libc and new kernels with the new libc interfaces.
>
> i dont believe you tested all layer combinations

I've tested everything I can, as has the autobuilder. I can't offer
any more than this.

>  >
>  >
>  >> at this point. 3.10 being LTS
>  >> I would assume its a better option to keep at 3.10
>  >
>  >
>  > I disagree, this is consistent with other releases and the documented
>  > plan of action. I'd rather not have a massive version jump in the fall.
>
> its probably not a bad option to stick to LTS version for kernel headers
> after all

Again, I disagree.

We can maybe keep the 3.10 recipe around, but the default should
be 3.14, we need a matched kernel and libc-headers to get the best 
integration
and leveraging of the latest features.

If we pull the headers, pull the kernel.

Bruce

>  >
>  > Sure 3.14 slipping out by a few weeks upstream was a problem, but its
>  > not like we haven't been testing with it.
>  >
>  > Bruce
>  >
>  >>
>  >
>
Khem Raj - April 1, 2014, 6:42 a.m.
On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:

>> i dont believe you tested all layer combinations
> 
> I've tested everything I can, as has the autobuilder. I can't offer
> any more than this.
> 
>> >
>> >
>> >> at this point. 3.10 being LTS
>> >> I would assume its a better option to keep at 3.10
>> >
>> >
>> > I disagree, this is consistent with other releases and the documented
>> > plan of action. I'd rather not have a massive version jump in the fall.
>> 
>> its probably not a bad option to stick to LTS version for kernel headers
>> after all
> 
> Again, I disagree.
> 
> We can maybe keep the 3.10 recipe around,

Thats ugly too. We decided to stick to one version of headers last time.

> but the default should
> be 3.14, we need a matched kernel and libc-headers to get the best integration
> and leveraging of the latest features.
> 
> If we pull the headers, pull the kernel.

this all is understood, however we have to get better with timings especially
changing something like kernel headers whose impact is far reaching then
 just updating kernel proper.
Bruce Ashfield - April 1, 2014, 12:54 p.m.
On 14-04-01 02:42 AM, Khem Raj wrote:
>
> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>
>>> i dont believe you tested all layer combinations
>>
>> I've tested everything I can, as has the autobuilder. I can't offer
>> any more than this.
>>
>>>>
>>>>
>>>>> at this point. 3.10 being LTS
>>>>> I would assume its a better option to keep at 3.10
>>>>
>>>>
>>>> I disagree, this is consistent with other releases and the documented
>>>> plan of action. I'd rather not have a massive version jump in the fall.
>>>
>>> its probably not a bad option to stick to LTS version for kernel headers
>>> after all
>>
>> Again, I disagree.
>>
>> We can maybe keep the 3.10 recipe around,
>
> Thats ugly too. We decided to stick to one version of headers last time.
>
>> but the default should
>> be 3.14, we need a matched kernel and libc-headers to get the best integration
>> and leveraging of the latest features.
>>
>> If we pull the headers, pull the kernel.
>
> this all is understood, however we have to get better with timings especially
> changing something like kernel headers whose impact is far reaching then
>   just updating kernel proper.

We do the best we can and I can only play the timing that is dealt
by the upstream projects ... but we all know that!

We arranged for as much soak testing and building as we could behind
the scenes.

That being said, we are going to introduce the versioned kernel and
libc-headers recipes in the -rc1 timeframe next time around and we
captured that intention on the kernel planning wiki for 1.7 .. so that
should help in the next cycle.

Cheers,

Bruce

>
Martin Jansa - April 1, 2014, 2:50 p.m.
On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote:
> On 14-04-01 02:42 AM, Khem Raj wrote:
> >
> > On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> >
> >>> i dont believe you tested all layer combinations
> >>
> >> I've tested everything I can, as has the autobuilder. I can't offer
> >> any more than this.
> >>
> >>>>
> >>>>
> >>>>> at this point. 3.10 being LTS
> >>>>> I would assume its a better option to keep at 3.10
> >>>>
> >>>>
> >>>> I disagree, this is consistent with other releases and the documented
> >>>> plan of action. I'd rather not have a massive version jump in the fall.
> >>>
> >>> its probably not a bad option to stick to LTS version for kernel headers
> >>> after all
> >>
> >> Again, I disagree.
> >>
> >> We can maybe keep the 3.10 recipe around,
> >
> > Thats ugly too. We decided to stick to one version of headers last time.
> >
> >> but the default should
> >> be 3.14, we need a matched kernel and libc-headers to get the best integration
> >> and leveraging of the latest features.
> >>
> >> If we pull the headers, pull the kernel.
> >
> > this all is understood, however we have to get better with timings especially
> > changing something like kernel headers whose impact is far reaching then
> >   just updating kernel proper.
> 
> We do the best we can and I can only play the timing that is dealt
> by the upstream projects ... but we all know that!
> 
> We arranged for as much soak testing and building as we could behind
> the scenes.
> 
> That being said, we are going to introduce the versioned kernel and
> libc-headers recipes in the -rc1 timeframe next time around and we
> captured that intention on the kernel planning wiki for 1.7 .. so that
> should help in the next cycle.

This failure also seems new:

|
/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24:
error: 'struct bio' has no member named 'bi_sector'
|    tp_assign(sector, bio->bi_sector)
|                         ^
Bruce Ashfield - April 1, 2014, 2:52 p.m.
On 14-04-01 10:50 AM, Martin Jansa wrote:
> On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote:
>> On 14-04-01 02:42 AM, Khem Raj wrote:
>>>
>>> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>>>
>>>>> i dont believe you tested all layer combinations
>>>>
>>>> I've tested everything I can, as has the autobuilder. I can't offer
>>>> any more than this.
>>>>
>>>>>>
>>>>>>
>>>>>>> at this point. 3.10 being LTS
>>>>>>> I would assume its a better option to keep at 3.10
>>>>>>
>>>>>>
>>>>>> I disagree, this is consistent with other releases and the documented
>>>>>> plan of action. I'd rather not have a massive version jump in the fall.
>>>>>
>>>>> its probably not a bad option to stick to LTS version for kernel headers
>>>>> after all
>>>>
>>>> Again, I disagree.
>>>>
>>>> We can maybe keep the 3.10 recipe around,
>>>
>>> Thats ugly too. We decided to stick to one version of headers last time.
>>>
>>>> but the default should
>>>> be 3.14, we need a matched kernel and libc-headers to get the best integration
>>>> and leveraging of the latest features.
>>>>
>>>> If we pull the headers, pull the kernel.
>>>
>>> this all is understood, however we have to get better with timings especially
>>> changing something like kernel headers whose impact is far reaching then
>>>    just updating kernel proper.
>>
>> We do the best we can and I can only play the timing that is dealt
>> by the upstream projects ... but we all know that!
>>
>> We arranged for as much soak testing and building as we could behind
>> the scenes.
>>
>> That being said, we are going to introduce the versioned kernel and
>> libc-headers recipes in the -rc1 timeframe next time around and we
>> captured that intention on the kernel planning wiki for 1.7 .. so that
>> should help in the next cycle.
>
> This failure also seems new:
>
> |
> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24:
> error: 'struct bio' has no member named 'bi_sector'
> |    tp_assign(sector, bio->bi_sector)

For qemuarm. Hmm. I did build lttng modules for it here, as I presume
the autobuilder did as well.

But I'll launch another build to see what happens here.

Bruce

> |                         ^
>
Richard Purdie - April 1, 2014, 2:54 p.m.
On Tue, 2014-04-01 at 10:52 -0400, Bruce Ashfield wrote:
> On 14-04-01 10:50 AM, Martin Jansa wrote:
> > On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote:
> >> On 14-04-01 02:42 AM, Khem Raj wrote:
> >>>
> >>> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> >>>
> >>>>> i dont believe you tested all layer combinations
> >>>>
> >>>> I've tested everything I can, as has the autobuilder. I can't offer
> >>>> any more than this.
> >>>>
> >>>>>>
> >>>>>>
> >>>>>>> at this point. 3.10 being LTS
> >>>>>>> I would assume its a better option to keep at 3.10
> >>>>>>
> >>>>>>
> >>>>>> I disagree, this is consistent with other releases and the documented
> >>>>>> plan of action. I'd rather not have a massive version jump in the fall.
> >>>>>
> >>>>> its probably not a bad option to stick to LTS version for kernel headers
> >>>>> after all
> >>>>
> >>>> Again, I disagree.
> >>>>
> >>>> We can maybe keep the 3.10 recipe around,
> >>>
> >>> Thats ugly too. We decided to stick to one version of headers last time.
> >>>
> >>>> but the default should
> >>>> be 3.14, we need a matched kernel and libc-headers to get the best integration
> >>>> and leveraging of the latest features.
> >>>>
> >>>> If we pull the headers, pull the kernel.
> >>>
> >>> this all is understood, however we have to get better with timings especially
> >>> changing something like kernel headers whose impact is far reaching then
> >>>    just updating kernel proper.
> >>
> >> We do the best we can and I can only play the timing that is dealt
> >> by the upstream projects ... but we all know that!
> >>
> >> We arranged for as much soak testing and building as we could behind
> >> the scenes.
> >>
> >> That being said, we are going to introduce the versioned kernel and
> >> libc-headers recipes in the -rc1 timeframe next time around and we
> >> captured that intention on the kernel planning wiki for 1.7 .. so that
> >> should help in the next cycle.
> >
> > This failure also seems new:
> >
> > |
> > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24:
> > error: 'struct bio' has no member named 'bi_sector'
> > |    tp_assign(sector, bio->bi_sector)
> 
> For qemuarm. Hmm. I did build lttng modules for it here, as I presume
> the autobuilder did as well.
> 
> But I'll launch another build to see what happens here.

I can confirm we didn't see that on the autobuilder...

Cheers,

Richard
Bruce Ashfield - April 1, 2014, 3:41 p.m.
On 14-04-01 10:54 AM, Richard Purdie wrote:
> On Tue, 2014-04-01 at 10:52 -0400, Bruce Ashfield wrote:
>> On 14-04-01 10:50 AM, Martin Jansa wrote:
>>> On Tue, Apr 01, 2014 at 08:54:42AM -0400, Bruce Ashfield wrote:
>>>> On 14-04-01 02:42 AM, Khem Raj wrote:
>>>>>
>>>>> On Mar 31, 2014, at 12:50 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>>>>>
>>>>>>> i dont believe you tested all layer combinations
>>>>>>
>>>>>> I've tested everything I can, as has the autobuilder. I can't offer
>>>>>> any more than this.
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> at this point. 3.10 being LTS
>>>>>>>>> I would assume its a better option to keep at 3.10
>>>>>>>>
>>>>>>>>
>>>>>>>> I disagree, this is consistent with other releases and the documented
>>>>>>>> plan of action. I'd rather not have a massive version jump in the fall.
>>>>>>>
>>>>>>> its probably not a bad option to stick to LTS version for kernel headers
>>>>>>> after all
>>>>>>
>>>>>> Again, I disagree.
>>>>>>
>>>>>> We can maybe keep the 3.10 recipe around,
>>>>>
>>>>> Thats ugly too. We decided to stick to one version of headers last time.
>>>>>
>>>>>> but the default should
>>>>>> be 3.14, we need a matched kernel and libc-headers to get the best integration
>>>>>> and leveraging of the latest features.
>>>>>>
>>>>>> If we pull the headers, pull the kernel.
>>>>>
>>>>> this all is understood, however we have to get better with timings especially
>>>>> changing something like kernel headers whose impact is far reaching then
>>>>>     just updating kernel proper.
>>>>
>>>> We do the best we can and I can only play the timing that is dealt
>>>> by the upstream projects ... but we all know that!
>>>>
>>>> We arranged for as much soak testing and building as we could behind
>>>> the scenes.
>>>>
>>>> That being said, we are going to introduce the versioned kernel and
>>>> libc-headers recipes in the -rc1 timeframe next time around and we
>>>> captured that intention on the kernel planning wiki for 1.7 .. so that
>>>> should help in the next cycle.
>>>
>>> This failure also seems new:
>>>
>>> |
>>> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemuarm-oe-linux-gnueabi/lttng-modules/2.3.3-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:344:24:
>>> error: 'struct bio' has no member named 'bi_sector'
>>> |    tp_assign(sector, bio->bi_sector)
>>
>> For qemuarm. Hmm. I did build lttng modules for it here, as I presume
>> the autobuilder did as well.
>>
>> But I'll launch another build to see what happens here.
>
> I can confirm we didn't see that on the autobuilder...

I was checking my core-image-kernel-dev builds for qemuarm, and managed
to confuse myself momentarily (when I didn't see a build trigger), and
then remembered.

------------

commit 7a974407379b43e40664cad4696b427ee8c18df0
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Thu Mar 6 22:26:19 2014 -0600

     lttng-modules: Exclude arm

     lttng-modules and gcc-4.8 don't mix, according to the lttng ML
     'current_thread_info() not respecting program order with gcc 4.8.x',
     so remove it from arm builds.

     (From OE-Core rev: ccf687de7b856dbe6f347956743f07ff05c2533a)

     Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

------------

Tom also has the fix for bio*:

commit b465c0cb32696eed3ecc42fe4b5b478e4ba07914
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Thu Mar 6 22:26:20 2014 -0600

     lttng-modules: Fix 3.14 bio tracepoints

     The mainline 3.14 commit 'block: Astract out bvec iterator' broke the
     lttng-modules tracepoints.  Fix them here.

     (From OE-Core rev: c11b29ff4f24af0445c3c6a694b8dc2037dcd7e4)

     Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

----------

So this one is expected, and avoided .. but of course if you build it
directly it will break.

If there's a fix that anyone knows of for ARM, I'm available to test
it here.

Summary: not introduced by the uprev directly, and it was known before
hand .. my foggy memory just managed to forget it..

Cheers,

Bruce

>
> Cheers,
>
> Richard
>

Patch

diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
index d6a626cfab8c..300deeaf5fb9 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -22,7 +22,7 @@  SDKGCCVERSION ?= "${GCCVERSION}"
 BINUVERSION ?= "2.24"
 EGLIBCVERSION ?= "2.19"
 UCLIBCVERSION ?= "0.9.33+git%"
-LINUXLIBCVERSION ?= "3.10"
+LINUXLIBCVERSION ?= "3.14"
 
 PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-cross ?= "${GCCVERSION}"