[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 2/2] x86/Kconfig: Introduce CONFIG_{AMD,INTEL} and conditionalise ucode
On 27.10.2023 21:18, Andrew Cooper wrote: > On 27/10/2023 2:47 pm, Roger Pau Monné wrote: >> On Fri, Oct 27, 2023 at 09:12:40AM +0200, Jan Beulich wrote: >>> On 26.10.2023 22:55, Andrew Cooper wrote: >>>> We eventually want to be able to build a stripped down Xen for a single >>>> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but >>>> available to randconfig), and adjust the microcode logic. >>>> >>>> No practical change. >>>> >>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >>>> --- >>>> CC: Jan Beulich <JBeulich@xxxxxxxx> >>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx> >>>> CC: Wei Liu <wl@xxxxxxx> >>>> CC: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx> >>>> CC: Stefano Stabellini <stefano.stabellini@xxxxxxx> >>>> CC: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx> >>>> >>>> I've intentionally ignored the other vendors for now. They can be put into >>>> Kconfig by whomever figures out the actual dependencies between their init >>>> routines. >>>> >>>> v2: >>>> * Tweak text >>> What about the indentation issues mentioned in reply to v1? >>> >>> As to using un-amended AMD and INTEL - Roger, what's your view here? >> I think it would be good to add a suffix, like we do for >> {AMD,INTEL}_IOMMU options, and reserve the plain AMD and INTEL options >> as platform/system level options that enable both VENDOR_{CPU,IOMMU} >> sub options. >> >> So yes, {INTEL,AMD}_CPU seems a good option. > > Really? You do realise that, unlike the IOMMU names, this is going to > be plastered all over the Makefiles and header files? > > And it breaks the careful attempt not to use the ambigous term when > describing what the symbol means. I wonder what you mean here: Describing what the symbol means is all done in plain text, i.e. independent of the symbol name. > I'll send out a v2.5 so you can see it in context, but I'm going to say > straight up - I think this is a mistake. So in the longer run perhaps we want CONFIG_{AMD,INTEL} _and_ CONFIG_{AMD,INTEL}_CPU? The former mainly to control the defaults of CONFIG_{AMD,INTEL}_{CPU,IOMMU} (could also be viewed as kind of a shorthand)? Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |