| Message ID | 1478793207-31255-1-git-send-email-vzakhar@synopsys.com |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Thu, 10 Nov 2016 18:53:27 +0300, Vlad Zakharov wrote: > 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 > > Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com> > --- > 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
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. On Fri, 2016-11-11 at 15:18 +0100, Thomas Petazzoni wrote: > Hello, > > On Thu, 10 Nov 2016 18:53:27 +0300, Vlad Zakharov wrote: > > > > 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 > > > > Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com> > > --- > > 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 -- Best regards, Vlad Zakharov <vzakhar@synopsys.com>
Hello, On Mon, 14 Nov 2016 12:32:29 +0000, Vlad Zakharov wrote: > 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
Hi Thomas, On Mon, 2016-11-14 at 15:07 +0100, Thomas Petazzoni wrote: > Hello, > > On Mon, 14 Nov 2016 12:32:29 +0000, Vlad Zakharov wrote: > > > > > 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 ? 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: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=840c054fd0efb048df6fceb0c46385ec5b66dfe6 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
Hello, On Mon, 14 Nov 2016 14:34:01 +0000, Alexey Brodkin wrote: > 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: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=840c054fd0efb048df6fceb0c46385ec5b66dfe6 > > 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
Hi Thomas, On Mon, 2016-11-14 at 15:42 +0100, Thomas Petazzoni wrote: > Hello, > > On Mon, 14 Nov 2016 14:34:01 +0000, Alexey Brodkin wrote: > > > > > 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: > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=840c054fd0efb048df6fceb0c46385ec5b66dfe6 > > > > 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. True. > 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
Hello, On Mon, 14 Nov 2016 14:46:43 +0000, Alexey Brodkin wrote: > 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
Alexey, All, On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly: [--SNIP--] > 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.
Hi Yann, On Mon, 2016-11-14 at 18:15 +0100, Yann E. MORIN wrote: > Alexey, All, > > On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly: > [--SNIP--] > > > > 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". ;-) 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
diff --git a/configs/snps_axs101_defconfig b/configs/snps_axs101_defconfig index f272853..eea7a50 100644 --- a/configs/snps_axs101_defconfig +++ b/configs/snps_axs101_defconfig @@ -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 diff --git a/configs/snps_axs103_defconfig b/configs/snps_axs103_defconfig index 75596c9..08c55de 100644 --- a/configs/snps_axs103_defconfig +++ b/configs/snps_axs103_defconfig @@ -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 diff --git a/configs/snps_hs38_smp_vdk_defconfig b/configs/snps_hs38_smp_vdk_defconfig index 32922f8..d4dcd1b 100644 --- a/configs/snps_hs38_smp_vdk_defconfig +++ b/configs/snps_hs38_smp_vdk_defconfig @@ -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
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 Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com> --- configs/snps_axs101_defconfig | 6 +++--- configs/snps_axs103_defconfig | 6 +++--- configs/snps_hs38_smp_vdk_defconfig | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-)