Hi,

We should do what our users are likely to do... they want stable
kernel, and will not update toolchain in middle of product
maintainance. [Updating toolchain when starting new product with given
-cip kernel is more likely].

I believe that means we should stick to specific version, but I'm not
sure what version it is. We support Debian distro, likely gcc version
from that distro would be a good option? Perhaps we should ask on TSC
meeting tommorow?

Yes, we recommend using GCC with the rootfs environment.
And weare using the same container at compile time.

5.10 kernel was released in Dec 2020. At that time, gcc 8 and 9 were
maintained, and gcc 10 was new (https://gcc.gnu.org/releases.html).

To get some results for -stable testing, easiest options might be to
disable gcc plugin support in Kconfig.

+1.
Also, I think that this will not be necessary by preparing a build container
that matches the kernel.

Best regards,
Nobuhiro
________________________________________
差出人: cip-dev@... <cip-dev@...> が Pavel Machek <pavel@...> の代理で送信
送信日時: 2021年12月20日 18:58
宛先: Chris Paterson
CC: Pavel Machek; cip-dev@...
件名: Re: [cip-dev] 5.10.85 breaks CIP testing Re: [PATCH 5.10 00/33] 5.10.86-rc1 review

Hi!

I believe we should not change build requirements in the middle of
stable series.

To our testing team: 5.10.85 introduced new requirements for the
build. gmp.h is now required in our configs, and maybe something else.

Hi Pavel, sorry for missing this email before now.
I can look into supporting this, depending on the answers to the comments below...

Thank you.

Easiest fix might be to add

# CONFIG_GCC_PLUGINS is not set

to our configs. Alternatively I know which patch to revert.

But I believe -stable should be the one doing the revert, as the patch
does not fix serious bug and introduces problem. Faster compile is
nice but let mainline have those kind of changes.

But that commit is needed to get gcc11 plugins to work with the 5.10.y
kernel tree. So either we "break" it for old and obsolete gcc versions
(i.e. gcc7), or newer supported versions break.

Well this leads us to an interesting point.
At the moment we use GCC v8.1.0 for building all of our kernel trees (cip & stable).
What does CIP want to do mid/long term? Keep upgrading the version we use? Or try and support a specific version of GCC for 10 years?
If the former, when do we want to upgrade?
If the latter, which version?

We should do what our users are likely to do... they want stable
kernel, and will not update toolchain in middle of product
maintainance. [Updating toolchain when starting new product with given
-cip kernel is more likely].

I believe that means we should stick to specific version, but I'm not
sure what version it is. We support Debian distro, likely gcc version
from that distro would be a good option? Perhaps we should ask on TSC
meeting tommorow?

5.10 kernel was released in Dec 2020. At that time, gcc 8 and 9 were
maintained, and gcc 10 was new (https://gcc.gnu.org/releases.html).

To get some results for -stable testing, easiest options might be to
disable gcc plugin support in Kconfig.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On 20.12.21 10:58, Pavel Machek wrote:

Hi!

I believe we should not change build requirements in the middle of
stable series.

To our testing team: 5.10.85 introduced new requirements for the
build. gmp.h is now required in our configs, and maybe something else.

Hi Pavel, sorry for missing this email before now.
I can look into supporting this, depending on the answers to the comments below...

Thank you.

Easiest fix might be to add

# CONFIG_GCC_PLUGINS is not set

to our configs. Alternatively I know which patch to revert.

But I believe -stable should be the one doing the revert, as the patch
does not fix serious bug and introduces problem. Faster compile is
nice but let mainline have those kind of changes.

But that commit is needed to get gcc11 plugins to work with the 5.10.y
kernel tree. So either we "break" it for old and obsolete gcc versions
(i.e. gcc7), or newer supported versions break.

Well this leads us to an interesting point.
At the moment we use GCC v8.1.0 for building all of our kernel trees (cip & stable).
What does CIP want to do mid/long term? Keep upgrading the version we use? Or try and support a specific version of GCC for 10 years?
If the former, when do we want to upgrade?
If the latter, which version?

We should do what our users are likely to do... they want stable
kernel, and will not update toolchain in middle of product
maintainance. [Updating toolchain when starting new product with given
-cip kernel is more likely].

I believe that means we should stick to specific version, but I'm not
sure what version it is. We support Debian distro, likely gcc version
from that distro would be a good option? Perhaps we should ask on TSC
meeting tommorow?

5.10 kernel was released in Dec 2020. At that time, gcc 8 and 9 were
maintained, and gcc 10 was new (https://gcc.gnu.org/releases.html).

To get some results for -stable testing, easiest options might be to
disable gcc plugin support in Kconfig.

Best regards,
Pavel

The natural pairing would be "buster/kernel 4.19/gcc-8" and
"bullseye/kernel 5.10/gcc-10", indeed.

I'm definitely not able to attend the TSC call tomorrow. If you want to
discuss this topic, someone would have to pick up the kernel WG
representation.

Jan

Hi!

I believe we should not change build requirements in the middle of
stable series.

To our testing team: 5.10.85 introduced new requirements for the
build. gmp.h is now required in our configs, and maybe something else.

Hi Pavel, sorry for missing this email before now.
I can look into supporting this, depending on the answers to the comments below...

Thank you.

Easiest fix might be to add

# CONFIG_GCC_PLUGINS is not set

to our configs. Alternatively I know which patch to revert.

But I believe -stable should be the one doing the revert, as the patch
does not fix serious bug and introduces problem. Faster compile is
nice but let mainline have those kind of changes.

But that commit is needed to get gcc11 plugins to work with the 5.10.y
kernel tree. So either we "break" it for old and obsolete gcc versions
(i.e. gcc7), or newer supported versions break.

Well this leads us to an interesting point.
At the moment we use GCC v8.1.0 for building all of our kernel trees (cip & stable).
What does CIP want to do mid/long term? Keep upgrading the version we use? Or try and support a specific version of GCC for 10 years?
If the former, when do we want to upgrade?
If the latter, which version?

We should do what our users are likely to do... they want stable
kernel, and will not update toolchain in middle of product
maintainance. [Updating toolchain when starting new product with given
-cip kernel is more likely].

I believe that means we should stick to specific version, but I'm not
sure what version it is. We support Debian distro, likely gcc version
from that distro would be a good option? Perhaps we should ask on TSC
meeting tommorow?

5.10 kernel was released in Dec 2020. At that time, gcc 8 and 9 were
maintained, and gcc 10 was new (https://gcc.gnu.org/releases.html).

To get some results for -stable testing, easiest options might be to
disable gcc plugin support in Kconfig.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From: cip-dev@... <cip-dev@...> On
Behalf Of Chris Paterson via lists.cip-project.org
Sent: 20 December 2021 07:17

Hello,

From: Greg Kroah-Hartman <gregkh@...>
Sent: 15 December 2021 18:40

On Wed, Dec 15, 2021 at 07:32:23PM +0100, Pavel Machek wrote:

Hi!

This is the start of the stable review cycle for the 5.10.86 release.
There are 33 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

I'm getting the gmp.h failures :-(.

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab

.com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-

%2Fpipelines%2F430434332&amp;data=04%7C01%7Cchris.paterson2%40ren

esas.com%7Cef488aaeb0b84b91a25a08d9bffa5dd5%7C53d82571da1947e49c

b4625a166a4a2a%7C0%7C0%7C637751904307960001%7CUnknown%7CTWFp

bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC

I6Mn0%3D%7C3000&amp;sdata=d4fq1iITMmiW79nbbG0Tf4srDwikrnVaPW%

2BH%2FITD9sY%3D&amp;reserved=0

I believe we should not change build requirements in the middle of
stable series.

To our testing team: 5.10.85 introduced new requirements for the
build. gmp.h is now required in our configs, and maybe something else.

Hi Pavel, sorry for missing this email before now.
I can look into supporting this, depending on the answers to the comments
below...

Easiest fix might be to add

# CONFIG_GCC_PLUGINS is not set

to our configs. Alternatively I know which patch to revert.

But I believe -stable should be the one doing the revert, as the patch
does not fix serious bug and introduces problem. Faster compile is
nice but let mainline have those kind of changes.

But that commit is needed to get gcc11 plugins to work with the 5.10.y
kernel tree. So either we "break" it for old and obsolete gcc versions
(i.e. gcc7), or newer supported versions break.

Well this leads us to an interesting point.
At the moment we use GCC v8.1.0 for building all of our kernel trees (cip &
stable).
What does CIP want to do mid/long term? Keep upgrading the version we
use? Or try and support a specific version of GCC for 10 years?
If the former, when do we want to upgrade?
If the latter, which version?

Note that I've done a quick build test [0] with GCC v11.1.0 and 5.10.y-cip seems to build okay.
If anyone wants to do something similar in their tests, edit your .gitlab-ci.yml as in [1].

[0] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/433007310
[1] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/commit/3185529010dfa5cd4ebe80d55b5c1c1ed23da4ce

Kind regards, Chris

Kind regards, Chris

We are not in the business of keeping older versions of gcc always
working, right?

thanks,

greg k-h

Hello,

From: Greg Kroah-Hartman <gregkh@...>
Sent: 15 December 2021 18:40

On Wed, Dec 15, 2021 at 07:32:23PM +0100, Pavel Machek wrote:

Hi!

This is the start of the stable review cycle for the 5.10.86 release.
There are 33 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

I'm getting the gmp.h failures :-(.

https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
.com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F-
%2Fpipelines%2F430434332&amp;data=04%7C01%7Cchris.paterson2%40ren
esas.com%7Cef488aaeb0b84b91a25a08d9bffa5dd5%7C53d82571da1947e49c
b4625a166a4a2a%7C0%7C0%7C637751904307960001%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
I6Mn0%3D%7C3000&amp;sdata=d4fq1iITMmiW79nbbG0Tf4srDwikrnVaPW%
2BH%2FITD9sY%3D&amp;reserved=0

I believe we should not change build requirements in the middle of
stable series.

To our testing team: 5.10.85 introduced new requirements for the
build. gmp.h is now required in our configs, and maybe something else.

Hi Pavel, sorry for missing this email before now.
I can look into supporting this, depending on the answers to the comments below...

Easiest fix might be to add

# CONFIG_GCC_PLUGINS is not set

to our configs. Alternatively I know which patch to revert.

But I believe -stable should be the one doing the revert, as the patch
does not fix serious bug and introduces problem. Faster compile is
nice but let mainline have those kind of changes.

But that commit is needed to get gcc11 plugins to work with the 5.10.y
kernel tree. So either we "break" it for old and obsolete gcc versions
(i.e. gcc7), or newer supported versions break.

Well this leads us to an interesting point.
At the moment we use GCC v8.1.0 for building all of our kernel trees (cip & stable).
What does CIP want to do mid/long term? Keep upgrading the version we use? Or try and support a specific version of GCC for 10 years?
If the former, when do we want to upgrade?
If the latter, which version?

Kind regards, Chris

We are not in the business of keeping older versions of gcc always
working, right?

thanks,

greg k-h