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 <[email protected]> > --- > 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..00000000 > --- 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..00000000 > --- 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 (#12249): https://lists.yoctoproject.org/g/linux-yocto/message/12249 Mute This Topic: https://lists.yoctoproject.org/mt/97420978/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
