Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU
On Tue, Mar 14, 2023 at 12:43 AM Naveen Saini wrote: > > Hi Bruce, > > Thank you for reviewing. > > > -Original Message- > > From: Bruce Ashfield > > Sent: Thursday, March 9, 2023 6:00 AM > > To: Saini, Naveen Kumar > > Cc: linux-yocto@lists.yoctoproject.org > > Subject: Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop > > RANDOM_TRUST_CPU > > > > Hi Naveen, > > > > I commented directly on one of the patches, and this 1/11 in particular is > > clear, but the other patches in the series are a little bit less unclear as > > to the > > overall goal. > > > > As Paul mentioned, a 0/N for the series would have helped explain the > > motivation. > > Yes, will make sure I provide that next time. > > > > > I didn't reply directly to the review and thread that started, as everyone > > had > > valid points to make. We have a balance to strike between enablement and > > also providing a streamlined base configuration. > > > > I'm adding the following, so it'll be captured in the archives: > > > > Generic demo and "works everywhere" configs have their place, and in our > > model, they are built up using the kernel features on top of a tuned > > baseline > > configuration. It is easier to add than to remove. So we turn on as little > > as > > possible, then have the kernel types, followed by kernel features triggered > > by distro or recipe space coordinated features. > > > > The baseline machine configurations shouldn't be guessing what the distro or > > image needs, and the distro or image shouldn't be undoing things that are > > done by the baseline configuration to tune/slim it down. Those baseline > > configs need to serve all the kernel types, they are also additive (for the > > most part .. tiny is the outlier), not subtractive. > > > > All that being said, the review and comments are exactly what I like to see. > > As we keep in mind that the machine/baseline configuration cannot possibly > > be all things to all configurations. Not all users of the kernel-cache have > > to > > adhere to the guidelines we have for the reference boards, kernel types, > > etc, but we can certainly try and guide them in that direction, which is the > > point of the shared repository of configuration fragments .. and that's what > > we are doing here. > > > > What the intel boards are doing, actually is quite close to what I described > > above. These are named features, and are included versus just adding the > > configs to a giant .cfg/.scc file. That means that someone doing a new BSP > > could decide what type of functionality to build on top of the baseline "it > > boots" configuration. Maybe some of the fragments doing most of the > > including could be named a bit differently, or be split a bit .. but that is > > something we can do as different functionality needs are found on the ends > > of the new > > -> old board spectrum. > > > > So my only real question was whether or not we can split the fragments out > > of common-pc, into a named fragment. > > For the ones being added in this series, I guess we can move them to a > separate named .scc/.cfg instead of including in intel-common- drivers.scc. > > We can also create a new config for intel-skylake-64 machine (which enables > relatively newer hardware) in meta-intel which can then turn on these > features by default. > > Or, we can just enable the features in .scc via KERNEL_FEATURES in meta-intel > so it's easier to disable or override if required. > > Please let us know what you think. For now, they are ok in the common fragment, they are named, so the logic for them is implicitly documented by the fragment names. So just the split out of common-pc options into a separate .scc is enough for v2. If there's much newer hardware, with significant additions that aren't appropriate or available for older boards, then we should consider a split for a new board family. Bruce > > > > > That, and I assume this is for master, since you mentioned 6.2. > > Yes, this is for master/6.2. > > Thanks, > Naveen > > > > > Bruce > > > > In message: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop > > RANDOM_TRUST_CPU on 06/03/2023 Naveen Saini wrote: > > > > > This option is no longer present in v6.2 as the following commit removed > > > it: > > > > > https://github.com/torvalds/linux/commit/b9b01a5625b5a9e9d96d14d4a813 > > a > > > 54e8a124f4b > > > > > > Signed-off-by: Navee
Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU
Hi Bruce, Thank you for reviewing. > -Original Message- > From: Bruce Ashfield > Sent: Thursday, March 9, 2023 6:00 AM > To: Saini, Naveen Kumar > Cc: linux-yocto@lists.yoctoproject.org > Subject: Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop > RANDOM_TRUST_CPU > > Hi Naveen, > > I commented directly on one of the patches, and this 1/11 in particular is > clear, but the other patches in the series are a little bit less unclear as > to the > overall goal. > > As Paul mentioned, a 0/N for the series would have helped explain the > motivation. Yes, will make sure I provide that next time. > > I didn't reply directly to the review and thread that started, as everyone had > valid points to make. We have a balance to strike between enablement and > also providing a streamlined base configuration. > > I'm adding the following, so it'll be captured in the archives: > > Generic demo and "works everywhere" configs have their place, and in our > model, they are built up using the kernel features on top of a tuned baseline > configuration. It is easier to add than to remove. So we turn on as little as > possible, then have the kernel types, followed by kernel features triggered > by distro or recipe space coordinated features. > > The baseline machine configurations shouldn't be guessing what the distro or > image needs, and the distro or image shouldn't be undoing things that are > done by the baseline configuration to tune/slim it down. Those baseline > configs need to serve all the kernel types, they are also additive (for the > most part .. tiny is the outlier), not subtractive. > > All that being said, the review and comments are exactly what I like to see. > As we keep in mind that the machine/baseline configuration cannot possibly > be all things to all configurations. Not all users of the kernel-cache have to > adhere to the guidelines we have for the reference boards, kernel types, > etc, but we can certainly try and guide them in that direction, which is the > point of the shared repository of configuration fragments .. and that's what > we are doing here. > > What the intel boards are doing, actually is quite close to what I described > above. These are named features, and are included versus just adding the > configs to a giant .cfg/.scc file. That means that someone doing a new BSP > could decide what type of functionality to build on top of the baseline "it > boots" configuration. Maybe some of the fragments doing most of the > including could be named a bit differently, or be split a bit .. but that is > something we can do as different functionality needs are found on the ends > of the new > -> old board spectrum. > > So my only real question was whether or not we can split the fragments out > of common-pc, into a named fragment. For the ones being added in this series, I guess we can move them to a separate named .scc/.cfg instead of including in intel-common- drivers.scc. We can also create a new config for intel-skylake-64 machine (which enables relatively newer hardware) in meta-intel which can then turn on these features by default. Or, we can just enable the features in .scc via KERNEL_FEATURES in meta-intel so it's easier to disable or override if required. Please let us know what you think. > > That, and I assume this is for master, since you mentioned 6.2. Yes, this is for master/6.2. Thanks, Naveen > > Bruce > > In message: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop > RANDOM_TRUST_CPU on 06/03/2023 Naveen Saini wrote: > > > This option is no longer present in v6.2 as the following commit removed it: > > > https://github.com/torvalds/linux/commit/b9b01a5625b5a9e9d96d14d4a813 > a > > 54e8a124f4b > > > > Signed-off-by: Naveen Saini > > --- > > bsp/intel-common/intel-common-drivers.scc | 1 - > > features/random/random.cfg| 2 -- > > features/random/random.scc| 5 - > > kern-features.rc | 1 - > > 4 files changed, 9 deletions(-) > > delete mode 100644 features/random/random.cfg delete mode 100644 > > features/random/random.scc > > > > diff --git a/bsp/intel-common/intel-common-drivers.scc > > b/bsp/intel-common/intel-common-drivers.scc > > index 59dc6750..33451730 100644 > > --- a/bsp/intel-common/intel-common-drivers.scc > > +++ b/bsp/intel-common/intel-common-drivers.scc > > @@ -85,7 +85,6 @@ include features/input/keyboard-gpio.scc include > > features/ciphers/ciphers.scc include features/pci-iov/pci-iov.scc > > include features/intel-tco/intel-tco.scc -include > > features/random/random.scc > >
Re: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU
Hi Naveen, I commented directly on one of the patches, and this 1/11 in particular is clear, but the other patches in the series are a little bit less unclear as to the overall goal. As Paul mentioned, a 0/N for the series would have helped explain the motivation. I didn't reply directly to the review and thread that started, as everyone had valid points to make. We have a balance to strike between enablement and also providing a streamlined base configuration. I'm adding the following, so it'll be captured in the archives: Generic demo and "works everywhere" configs have their place, and in our model, they are built up using the kernel features on top of a tuned baseline configuration. It is easier to add than to remove. So we turn on as little as possible, then have the kernel types, followed by kernel features triggered by distro or recipe space coordinated features. The baseline machine configurations shouldn't be guessing what the distro or image needs, and the distro or image shouldn't be undoing things that are done by the baseline configuration to tune/slim it down. Those baseline configs need to serve all the kernel types, they are also additive (for the most part .. tiny is the outlier), not subtractive. All that being said, the review and comments are exactly what I like to see. As we keep in mind that the machine/baseline configuration cannot possibly be all things to all configurations. Not all users of the kernel-cache have to adhere to the guidelines we have for the reference boards, kernel types, etc, but we can certainly try and guide them in that direction, which is the point of the shared repository of configuration fragments .. and that's what we are doing here. What the intel boards are doing, actually is quite close to what I described above. These are named features, and are included versus just adding the configs to a giant .cfg/.scc file. That means that someone doing a new BSP could decide what type of functionality to build on top of the baseline "it boots" configuration. Maybe some of the fragments doing most of the including could be named a bit differently, or be split a bit .. but that is something we can do as different functionality needs are found on the ends of the new -> old board spectrum. So my only real question was whether or not we can split the fragments out of common-pc, into a named fragment. That, and I assume this is for master, since you mentioned 6.2. Bruce In message: [linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU on 06/03/2023 Naveen Saini wrote: > This option is no longer present in v6.2 as the following commit removed it: > https://github.com/torvalds/linux/commit/b9b01a5625b5a9e9d96d14d4a813a54e8a124f4b > > Signed-off-by: Naveen Saini > --- > bsp/intel-common/intel-common-drivers.scc | 1 - > features/random/random.cfg| 2 -- > features/random/random.scc| 5 - > kern-features.rc | 1 - > 4 files changed, 9 deletions(-) > delete mode 100644 features/random/random.cfg > delete mode 100644 features/random/random.scc > > diff --git a/bsp/intel-common/intel-common-drivers.scc > b/bsp/intel-common/intel-common-drivers.scc > index 59dc6750..33451730 100644 > --- a/bsp/intel-common/intel-common-drivers.scc > +++ b/bsp/intel-common/intel-common-drivers.scc > @@ -85,7 +85,6 @@ include features/input/keyboard-gpio.scc > include features/ciphers/ciphers.scc > include features/pci-iov/pci-iov.scc > include features/intel-tco/intel-tco.scc > -include features/random/random.scc > > # default policy for standard kernels > include cfg/usb-mass-storage.scc > diff --git a/features/random/random.cfg b/features/random/random.cfg > deleted file mode 100644 > index bacab3cb.. > --- a/features/random/random.cfg > +++ /dev/null > @@ -1,2 +0,0 @@ > -# SPDX-License-Identifier: MIT > -CONFIG_RANDOM_TRUST_CPU=y > diff --git a/features/random/random.scc b/features/random/random.scc > deleted file mode 100644 > index 0fd6584c.. > --- a/features/random/random.scc > +++ /dev/null > @@ -1,5 +0,0 @@ > -# SPDX-License-Identifier: MIT > -define KFEATURE_DESCRIPTION "Trust CPU's random number generator for > initializing kernel's CRNG" > -define KFEATURE_COMPATIBILITY arch > - > -kconf hardware random.cfg > diff --git a/kern-features.rc b/kern-features.rc > index 4a55ed4f..c531c62f 100644 > --- a/kern-features.rc > +++ b/kern-features.rc > @@ -124,7 +124,6 @@ > config = features/rpmb/rpmb-sim.scc > config = features/rpmb/rpmb-uapi.scc > config = features/rpmb/rpmb-base.scc > - config = features/random/random.scc > config = features/usb/usb-raw-gadget.scc > config = features/usb/designware-usb3.scc > config = features/
[linux-yocto] [kernel-cache][PATCH 01/11] features: drop RANDOM_TRUST_CPU
This option is no longer present in v6.2 as the following commit removed it: https://github.com/torvalds/linux/commit/b9b01a5625b5a9e9d96d14d4a813a54e8a124f4b Signed-off-by: Naveen Saini --- bsp/intel-common/intel-common-drivers.scc | 1 - features/random/random.cfg| 2 -- features/random/random.scc| 5 - kern-features.rc | 1 - 4 files changed, 9 deletions(-) delete mode 100644 features/random/random.cfg delete mode 100644 features/random/random.scc diff --git a/bsp/intel-common/intel-common-drivers.scc b/bsp/intel-common/intel-common-drivers.scc index 59dc6750..33451730 100644 --- a/bsp/intel-common/intel-common-drivers.scc +++ b/bsp/intel-common/intel-common-drivers.scc @@ -85,7 +85,6 @@ include features/input/keyboard-gpio.scc include features/ciphers/ciphers.scc include features/pci-iov/pci-iov.scc include features/intel-tco/intel-tco.scc -include features/random/random.scc # default policy for standard kernels include cfg/usb-mass-storage.scc diff --git a/features/random/random.cfg b/features/random/random.cfg deleted file mode 100644 index bacab3cb.. --- a/features/random/random.cfg +++ /dev/null @@ -1,2 +0,0 @@ -# SPDX-License-Identifier: MIT -CONFIG_RANDOM_TRUST_CPU=y diff --git a/features/random/random.scc b/features/random/random.scc deleted file mode 100644 index 0fd6584c.. --- a/features/random/random.scc +++ /dev/null @@ -1,5 +0,0 @@ -# SPDX-License-Identifier: MIT -define KFEATURE_DESCRIPTION "Trust CPU's random number generator for initializing kernel's CRNG" -define KFEATURE_COMPATIBILITY arch - -kconf hardware random.cfg diff --git a/kern-features.rc b/kern-features.rc index 4a55ed4f..c531c62f 100644 --- a/kern-features.rc +++ b/kern-features.rc @@ -124,7 +124,6 @@ config = features/rpmb/rpmb-sim.scc config = features/rpmb/rpmb-uapi.scc config = features/rpmb/rpmb-base.scc - config = features/random/random.scc config = features/usb/usb-raw-gadget.scc config = features/usb/designware-usb3.scc config = features/usb/usb-gadgets.scc -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12215): https://lists.yoctoproject.org/g/linux-yocto/message/12215 Mute This Topic: https://lists.yoctoproject.org/mt/97420978/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
