* Add 3.7 version of linux-libc-headers @ 2012-12-11 10:12 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 0 siblings, 2 replies; 9+ messages in thread From: Marcin Juszkiewicz @ 2012-12-11 10:12 UTC (permalink / raw) To: openembedded-core 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] linux-libc-headers: add 3.7 version 2012-12-11 10:12 Add 3.7 version of linux-libc-headers Marcin Juszkiewicz @ 2012-12-11 10:12 ` Marcin Juszkiewicz 2012-12-11 10:52 ` Add 3.7 version of linux-libc-headers Bruce Ashfield 1 sibling, 0 replies; 9+ messages in thread From: Marcin Juszkiewicz @ 2012-12-11 10:12 UTC (permalink / raw) To: openembedded-core Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> --- meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb new file mode 100644 index 0000000..3d688b7 --- /dev/null +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb @@ -0,0 +1,4 @@ +require linux-libc-headers.inc + +SRC_URI[md5sum] = "5323f3faadd051e83af605a63be5ea2e" +SRC_URI[sha256sum] = "dc08d87a579fe2918362e6666e503a95a76296419195cb499aa9dd4dbe171a9e" -- 1.8.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 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 ` Bruce Ashfield 2012-12-18 11:07 ` Richard Purdie 1 sibling, 1 reply; 9+ messages in thread From: Bruce Ashfield @ 2012-12-11 10:52 UTC (permalink / raw) To: Marcin Juszkiewicz; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1299 bytes --] 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. Cheers, Bruce > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" [-- Attachment #2: Type: text/html, Size: 2296 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-11 10:52 ` Add 3.7 version of linux-libc-headers Bruce Ashfield @ 2012-12-18 11:07 ` Richard Purdie 2012-12-18 13:32 ` Bruce Ashfield 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2012-12-18 11:07 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches, discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-18 11:07 ` Richard Purdie @ 2012-12-18 13:32 ` Bruce Ashfield 2012-12-18 13:41 ` Marcin Juszkiewicz 0 siblings, 1 reply; 9+ messages in thread From: Bruce Ashfield @ 2012-12-18 13:32 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3219 bytes --] On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie < richard.purdie@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@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" [-- Attachment #2: Type: text/html, Size: 4379 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-18 13:32 ` Bruce Ashfield @ 2012-12-18 13:41 ` Marcin Juszkiewicz 2012-12-18 13:56 ` Bruce Ashfield 0 siblings, 1 reply; 9+ messages in thread From: Marcin Juszkiewicz @ 2012-12-18 13:41 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer W dniu 18.12.2012 14:32, Bruce Ashfield pisze: > On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, 2012-12-11 at >> 05:52 -0500, Bruce Ashfield wrote: >>> On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz >>> 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. >> 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. I need 3.7 for AArch64 as this is first version which has support for it. >> 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. Remember that even when l-l-h 3.7 will be present in repo 3.4 can be still used as default one. > 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 ? I am fine with it. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-18 13:41 ` Marcin Juszkiewicz @ 2012-12-18 13:56 ` Bruce Ashfield 2012-12-18 17:32 ` Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Bruce Ashfield @ 2012-12-18 13:56 UTC (permalink / raw) To: Marcin Juszkiewicz; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3394 bytes --] On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz < marcin.juszkiewicz@linaro.org> wrote: > W dniu 18.12.2012 14:32, Bruce Ashfield pisze: > > On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, 2012-12-11 at > >> 05:52 -0500, Bruce Ashfield wrote: > >>> On Tue, Dec 11, 2012 at 5:12 AM, Marcin Juszkiewicz > > >>> 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. > > >> 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. > > I need 3.7 for AArch64 as this is first version which has support for it. > Yep, I didn't mean to imply that 3.4 would work for your needs as well, sorry if it came across that way. I assume 3.8+ will be ok for your case as well, since when we jump to the 1.4 kernel, the standing plan of purging all the headers and go back to a single version that matches that kver was going to kick in. I don't want to break your builds. > > >> 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. > > Remember that even when l-l-h 3.7 will be present in repo 3.4 can be > still used as default one. > Absolutely. We are just trying to keep things small and clean and avoid having multiple options and then using defaults/preferences to pick .. unless required. We can always pretend things are simple and clean :) > > > 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 ? > > I am fine with it. > Thanks, I'll pull this in if Richard agrees. Cheers, Bruce -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" [-- Attachment #2: Type: text/html, Size: 4677 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-18 13:56 ` Bruce Ashfield @ 2012-12-18 17:32 ` Richard Purdie 2013-01-03 21:14 ` Bruce Ashfield 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2012-12-18 17:32 UTC (permalink / raw) To: Bruce Ashfield; +Cc: Patches, discussions about the oe-core layer On Tue, 2012-12-18 at 08:56 -0500, Bruce Ashfield wrote: > On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz > <marcin.juszkiewicz@linaro.org> wrote: > W dniu 18.12.2012 14:32, Bruce Ashfield pisze: > > On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, > 2012-12-11 > > 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 ? > > > I am fine with it. > > Thanks, I'll pull this in if Richard agrees. > Sounds like a plan to me. Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Add 3.7 version of linux-libc-headers 2012-12-18 17:32 ` Richard Purdie @ 2013-01-03 21:14 ` Bruce Ashfield 0 siblings, 0 replies; 9+ messages in thread From: Bruce Ashfield @ 2013-01-03 21:14 UTC (permalink / raw) To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1653 bytes --] On Tue, Dec 18, 2012 at 12:32 PM, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Tue, 2012-12-18 at 08:56 -0500, Bruce Ashfield wrote: > > > On Tue, Dec 18, 2012 at 8:41 AM, Marcin Juszkiewicz > > <marcin.juszkiewicz@linaro.org> wrote: > > W dniu 18.12.2012 14:32, Bruce Ashfield pisze: > > > On Tue, Dec 18, 2012 at 6:07 AM, Richard Purdie On Tue, > > 2012-12-11 > > > > 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 ? > > > > > > I am fine with it. > > > > Thanks, I'll pull this in if Richard agrees. > > > > Sounds like a plan to me. > > FYI: I haven't forgotten about this, all the changes are done and tested here. I'm finished digging out of my holiday email queue and will start sending changes out tomorrow if all goes well. Cheers, Bruce > Cheers, > > Richard > > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" [-- Attachment #2: Type: text/html, Size: 2591 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-01-03 21:29 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.