[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 15:26) Alexander Kanavin wrote:
> On Tue, 7 Mar 2023 at 12:07, Paul Gortmaker > <[email protected]> wrote: > > 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. > > ... > > > 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. > > I beg to differ, strongly. > > I do enjoy meta-intel having only two (and a half) machine > definitions, and will resist attempts to degrade it to an arm-like zoo > of boards. The generic machines work pretty well and keep me pleased: > you can build any image against them, and that image will boot on any > reasonable x86 hardware, from the laptop in front of me to various > industrial PCs (I had three different customers with them just in the > past 6 months). You make some valid points, and I too still use the kernel's "defconfig" when I need to test something generic. But you didn't address any of the other concerns I raised - like ensuring that the x86 config doesn't go down the road to becoming a giant "allmodconfig" Maybe there is room for both - the best effort for "works for most" and also a more fine grained tuned platform config. > On the other hand, targeting specific boards will inevitably mean that > those targets will get less testing and QA, will break mysteriously > due to that, and will not be covering the complete list of what is out That is a good thing. If people aren't using something, it naturally ages out due to bitrot that nobody notices. If someone does care, they can compare the defconfig which works against the platform config and send an update. > there. And so what if the existing machines enable everything under > the sun and install it onto the image? If conserving disk space is a > business requirement, it can be addressed by replacing recommendations > with a targeted list of modules and firmwares. Unfortunately, not everything is a module. As to your "so what if the existing machines enable everything under the sun and install it onto the image" -- well obviously if people are evaluating Yocto for use in a system with limited storage, and the initrd is 2x bigger than their on-board storage size, then they are likely to just look elsewhere. I'm not looking to be argumentative or claiming I have the right answer; but I would like to see an open discussion on how to handle x86 platforms in a way that meets both needs and lets Yocto/OE benefit. Paul. -- > > Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12231): https://lists.yoctoproject.org/g/linux-yocto/message/12231 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]] -=-=-=-=-=-=-=-=-=-=-=-
