config: bump linux kernel to 4.8.6 in synopsys defconfigs
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
With this commit we update ARC defconfigs with the following:
- "snps_axs101_defconfig", "snps_axs103_defconfig" and "snps_hs38_smp_vdk_defconfig":
- bump linux kernel version to 4.8.6
- set up host linux headers to 4.8
--- configs/snps_axs101_defconfig | 6 +++--- configs/snps_axs103_defconfig | 6 +++--- configs/snps_hs38_smp_vdk_defconfig | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-)
configs/snps_axs101_defconfig +3 -3
@@ -8,13 +8,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y BR2_SYSTEM_DHCP="eth0" BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay" -# Linux headers same as kernel, a 4.7 series -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y +# Linux headers same as kernel, a 4.8 series +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6" BR2_LINUX_KERNEL_DEFCONFIG="axs101" # Bootloader
configs/snps_axs103_defconfig +3 -3
@@ -9,13 +9,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y BR2_SYSTEM_DHCP="eth0" BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay" -# Linux headers same as kernel, a 4.7 series -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y +# Linux headers same as kernel, a 4.8 series +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6" BR2_LINUX_KERNEL_DEFCONFIG="axs103_smp" # Bootloader
configs/snps_hs38_smp_vdk_defconfig +3 -3
@@ -8,12 +8,12 @@ BR2_TARGET_GENERIC_ISSUE="Welcome to the HS38 VDK Software Development Platform" BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay" BR2_TARGET_ROOTFS_EXT2=y -# Linux headers same as kernel, a 4.7 series -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y +# Linux headers same as kernel, a 4.8 series +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y # Kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6" BR2_LINUX_KERNEL_DEFCONFIG="vdk_hs38_smp" BR2_LINUX_KERNEL_VMLINUX=y
Signature · 1 line
2.6.3
Thomas Petazzoni
AppliedPATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hello,
Quoted 7 lines · Vlad Zakharov
With this commit we update ARC defconfigs with the following:
- "
snps_axs101_defconfig", "snps_axs103_defconfig" and "snps_hs38_smp_vdk_defconfig":
- bump linux kernel version to 4.8.6
- set up host linux headers to 4.8
Quoted 6 lines
Signed-off-by Vlad Zakharov <[email protected]>--- configs/snps_axs101_defconfig | 6 +++--- configs/snps_axs103_defconfig | 6 +++--- configs/snps_hs38_smp_vdk_defconfig | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-)
Applied to next, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hi Thomas,
We apologize for coming late with that update.
But could you please apply it on master as it is important for us to come up with latest kernel in upcoming Buildroot release. Updated configs were build- and run tested on corresponding platforms, so there shouldn't be any regressions there.
Thanks.
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 8 lines · Vlad Zakharov
With this commit we update ARC defconfigs with the following:
? - "
snps_axs101_defconfig", "snps_axs103_defconfig" and ????"snps_hs38_smp_vdk_defconfig":
?????- bump linux kernel version to 4.8.6 ?????- set up host linux headers to 4.8Quoted 6 lines
Signed-off-by Vlad Zakharov <[email protected]>---
?configs/snps_axs101_defconfig???????| 6 +++--- ?configs/snps_axs103_defconfig???????| 6 +++--- ?configs/snps_hs38_smp_vdk_defconfig | 6 +++---?3 files changed, 9 insertions(+), 9 deletions(-)
Applied to next, thanks.
Thomas
Signature · 2 lines
Best regards, Vlad Zakharov <[email protected]>
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hello,
Quoted 3 lines · Vlad Zakharov
We apologize for coming late with that update.
But could you please apply it on master as it is important for us to come up with latest kernel in upcoming Buildroot release. Updated configs were build- and run tested on corresponding platforms, so there shouldn't be any regressions there.
Once -rc1 has passed, we don't apply version bumps (be it to packages or defconfigs), unless they fix a specific issue.
What is the issue with having this update part of 2017.02 ?
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hi Thomas,
Quoted 10 lines · Thomas Petazzoni
Hello,
Quoted 5 lines · Vlad Zakharov
We apologize for coming late with that update.
But could you please apply it on master as it is important for us to come up with latest kernel in upcoming Buildroot release.
Updated configs were build- and run tested on corresponding platforms, so there shouldn't be any regressions there.
Quoted 4 lines
Once -rc1 has passed, we don't apply version bumps (be it to packages or defconfigs), unless they fix a specific issue.
What is the issue with having this update part of 2017.02 ?
Obviously since we live in upstream everything that could not be applied to stable branches (i.e. is not a trivial fix and longer than 200 lines) get merged in newer kernels.
In particular following commit was not accepted in backports:
See discussion here?http://www.spinics.net/lists/stable/msg143544.html
The problem is in GCC v6.x newer ABI is used for ARCv2 and so only kernels v4.8+ will work. I.e. existing 4.7 will fail to run user-space apps built with GCC 6.x.
Indeed we may add mentioned off-the-tree patch in BR for 4.7 but I'd rather bump kernel version here with which we get more fixes across the tree for our users.
-Alexey
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hello,
Quoted 9 lines · Alexey Brodkin
Obviously since we live in upstream everything that could not be applied to stable branches (i.e. is not a trivial fix and longer than 200 lines) get merged in newer kernels.
In particular following commit was not accepted in backports:
Quoted 7 lines
See discussion here?http://www.spinics.net/lists/stable/msg143544.html
The problem is in GCC v6.x newer ABI is used for ARCv2 and so only kernels v4.8+ will work. I.e. existing 4.7 will fail to run user-space apps built with GCC 6.x.
Indeed we may add mentioned off-the-tree patch in BR for 4.7 but I'd rather bump kernel version here with which we get more fixes across the tree for our users.
Since gcc 6.x is now used for ARC if I'm correct, this means that upgrading the defconfig to Linux 4.8 is mandatory to have them working. So it's actually a bug fix, which means the update can be applied to master.
Why hasn't this been explained in the commit log? The commit log is essential in deciding to apply in master or in next. Since the commit log was just "Let's bump to a newer kernel", I applied to the next branch. If the commit log had been "Since gcc 6.x is now the default on ARC, and gcc 6.x implements a newer ABI only supported by Linux 4.8 onwards, we must bump the kernel version of the ARC defconfigs in order to have them work correctly".
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hi Thomas,
Quoted 19 lines · Thomas Petazzoni
Hello,
Quoted 15 lines · Alexey Brodkin
Obviously since we live in upstream everything that could not be applied to stable branches (i.e. is not a trivial fix and longer than 200 lines) get merged in newer kernels.
In particular following commit was not accepted in backports:
See discussion here?http://www.spinics.net/lists/stable/msg143544.html
The problem is in GCC v6.x newer ABI is used for ARCv2 and so only kernels v4.8+ will work. I.e. existing 4.7 will fail to run user-space apps built with GCC 6.x.
Quoted 7 lines
Quoted 2 lines
Indeed we may add mentioned off-the-tree patch in BR for 4.7 but I'd rather bump kernel version here with which we get more fixes across the tree for our users.
Since gcc 6.x is now used for ARC if I'm correct, this means that upgrading the defconfig to Linux 4.8 is mandatory to have them working. So it's actually a bug fix, which means the update can be applied to master.
True.
Quoted 7 lines
Why hasn't this been explained in the commit log? The commit log is essential in deciding to apply in master or in next. Since the commit log was just "Let's bump to a newer kernel", I applied to the next branch. If the commit log had been "Since gcc 6.x is now the default on ARC, and gcc 6.x implements a newer ABI only supported by Linux 4.8 onwards, we must bump the kernel version of the ARC defconfigs in order to have them work correctly".
Right, I should have asked Vlad to modify his commit log.
The point is we were sitting on the patch for quite some time and when we saw RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
Do you want v2 with modified log to be sent so you may apply it to master branch?
-Alexey
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hello,
Quoted 6 lines · Alexey Brodkin
Right, I should have asked Vlad to modify his commit log.
The point is we were sitting on the patch for quite some time and when we saw RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
Do you want v2 with modified log to be sent so you may apply it to master branch?
No, I'll just cherry-pick the commit from next to master, and amend the commit log a bit.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
In reply to Alexey BrodkinAlexey, All,
On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly:
[--SNIP--]
Quoted 2 lines
The point is we were sitting on the patch for quite some time and when we saw RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
"Unexpectedly" is a bit of untrue: we've been doing releases every three months since February 2009, 7 years ago, with a one-month freeze before the release.
So, anything that comes on-or-after the first day of the release month is not guaranteed to go in master, unless it is a fix.
This is far from "unexpected". ;-)
Granted, the rc1 tag can be (and has often been) delayed by a few days, but this is a minor delay; it has never been guaranteed the first few days of the stabilisation month would still be open for merging into master...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 config: bump linux kernel to 4.8.6 in synopsys defconfigs
Hi Yann,
Quoted 8 lines · Yann E. MORIN
Alexey, All,
On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly:
[--SNIP--]Quoted 3 lines
The point is we were sitting on the patch for quite some time and when we saw RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
Quoted 8 lines
"Unexpectedly" is a bit of untrue: we've been doing releases every three months since February 2009, 7 years ago, with a one-month freeze before the release.
So, anything that comes on-or-after the first day of the release month is not guaranteed to go in master, unless it is a fix.
This is far from "unexpected". ;-)
I think you understood my sarcasm.
Frankly on my first submission of defconfigs for ARC boards I intentionally left kernel version unspecified, i.e. the most recent kernel in BR was used implicitly there. The reason was to stick to latest because all development for ARC happens upstream and there's really no reason to use anything except latest stable.
Well I may foresee very rare situations when latest stable is broken for us and so we will urgently change version... but usually that's not the case.
Instead now we have to bump kernel version either every month so users of BR from its master branch use latest kernel or at least right before RC1 so we have latest in the release... IMHO that's a bit of overhead.
I'm not sure if described approach makes sense for many defconfigs in BR, probably this is only ARC issue but I'd prefer it to be solved in some "automated" way instead of following:
?a) Bumps in stable repo and then
?b) Bumps of default kernel version in BR
Any thoughts?
-Alexey