[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[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

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(-)

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
-- 
2.6.3

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Vlad Zakharov]

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>

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Alexey Brodkin]

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

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Alexey Brodkin]

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

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs

[Alexey Brodkin]

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