[RE: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: Add support for Time-Sensitive Network] On 07/03/2023 (Tue 03:29) Saini, Naveen Kumar wrote:
> > > > -----Original Message----- > > From: [email protected] <linux- > > [email protected]> On Behalf Of Paul Gortmaker > > Sent: Tuesday, March 7, 2023 12:20 AM > > To: Saini, Naveen Kumar <[email protected]> > > Cc: [email protected] > > Subject: Re: [linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64- > > preempt-rt: Add support for Time-Sensitive Network > > > > [[linux-yocto] [kernel-cache][PATCH 08/11] bsp/intel-corei7-64-preempt-rt: > > Add support for Time-Sensitive Network] On 06/03/2023 (Mon 16:52) > > Naveen Saini via lists.yoctoproject.org wrote: > > > > > Signed-off-by: Naveen Saini <[email protected]> > > > --- > > > bsp/intel-common/intel-corei7-64-preempt-rt.scc | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > index 8ec001cb..9ce0b97a 100644 > > > --- a/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > +++ b/bsp/intel-common/intel-corei7-64-preempt-rt.scc > > > @@ -11,3 +11,6 @@ include ktypes/preempt-rt/preempt-rt.scc include > > > intel-common-drivers.scc include intel-developer-drivers.scc include > > > intel-corei7-64.scc > > > + > > > +# Time-Sensitive Network > > > +include features/tsn/tsn.scc > > > > There is at least a decade worth of i7 CPU out there that don't have TSN > > support, IIRC. > > > > I can't help but think that this, and a lot of the other options you've > > enabled > > in this series are aimed at the latest and greatest, but will just add > > bloat to a > > lot of other lower end (and older) x86-64 platforms. > > Especially anything that lands in intel-common/intel-common-drivers.scc > > Thank you for reviewing. > > Yes, the goal was to enable newer features for more recent platforms from > last 2-3 years so meta-intel kernel with MACHINE values works without having > to add all these to KERNEL_FEATURES while building. OK - please use --cover-letter next time, and capture the details in the 0000-<name> template file so people know what you are trying to do. > > > > I can't really tell what the goal was, since your series didn't have the > > typical > > "[0/11] intel: add options for ...." explanation preamble. > > > > But it seems like perhaps maybe it is time to create a new file under the > > bsp/intel-common dir that reflects a certain board or family of products > > that > > have these features -- vs. being confined to the existing categorization > > dictated by existing files? > > That can be done. Are you suggesting that we add a MACHINE specific new file > here and enable these newer features in that file (like Wind River does it > using bsp/intel-x86?). But, even then won't we always have this problem > whenever we have a set of new features that need to be enabled? I'm open to whatever implementation specifics make sense. I can see how declaring a new MACHINE to cover a family of boards would work nicely. Imagine if you created a MACHINE for "Thin Canyon" NUC products from 2014 -- sadly now almost 10 years ago: https://www.intel.ca/content/www/ca/en/products/sku/78577/intel-nuc-kit-de3815tykhe/specifications.html?wapkw=DE3815TYKHE and called it intel-NUC-gen2 or whatever made sense at the time. People who care about that platform would hence - here and now - not be impacted by your driver additions on their low end/ low RAM machine. And you'll benefit on new hardware because you won't have to drag along old Kconfig settings only used by 10 year old platforms, or enable the lowest common denominator like CONFIG_MATOM on server boards. The old configs naturally age out as the user base diminishes and you are 100% free to set content for new stuff w/o handcuffs of history. Contrast that with attempting to maintain what amounts to an "intel-defconfig" setup - which will always try to please everyone across all boards and procfams -- and hence will never please anyone. > All these configuration fragments are being enabled in intel-x86/ config as > well and will be enabled in the new file we add so it just seems like a lot > of work will be duplicated to avoid having to create a new baseline/common > set of configs ... What if we create a intel- > common/intel-common-drivers-extra.scc which enables these configs so > intel-common-drivers.scc can continue to have a base set? The directory name with "common" in it is an unfortunate bit of history that dates back to 2005 when support for a "common-pc" was modeled after a kernel defconfig and a COTS white-box Pentium4 home computer of the day. So, ignore the "common" -- the world has changed and so has intel -- there are now a wide range of x86 processors and platforms. The idea of having a "one config fits all" never really worked, but it definitely does not work in 2023. Paul. -- > > > > > Maybe you can describe what your end goal was, and we can go from there. > > > > Paul. > > -- > > > > > -- > > > 2.25.1 > > > > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12229): https://lists.yoctoproject.org/g/linux-yocto/message/12229 Mute This Topic: https://lists.yoctoproject.org/mt/97420986/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
