On 11/7/18, Palmer Dabbelt <pal...@sifive.com> wrote: > On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote: >> On 11/5/18, Christoph Hellwig <h...@infradead.org> wrote: >>> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: >>>> Many thanks for kinds of comments. I quickly synthesize the comments >>>> and >>>> list them as below. >>>> 1. The kernel image shall include all vendor-specific code. >>> >>> I fundamentally disagree with this… and think it should be the contrary. >>> >>> 1. The kernel shall support no vendor specific instructions whatsoever, >>> period. >> >> I think what was meant above is >> >> 1. If a vendor extension requires kernel support, that support >> must be able to be built into a kernel image without breaking support >> for CPUs that do not have that extension, to allow building a single >> kernel image that works on all CPUs. > > Yes. I don't want anything that won't compile with upstream GCC, but I also > > don't want to have a Kconfig that says "make the kernel only work on > $VENDOR's implementation". I think this can be achieved, at least for the > cases I've seen so far.
I think over time, the implementations will diverge. Ignoring the question of vendor extensions for the moment, you will definitely have to deal with combinations of (future) standard extensions. I can see two ways of doing that: Either each extension is a separate Kconfig option and you have to know which one to enable or disable for a particular target, or you list each platform separately with one Kconfig option, and have Kconfig/Kbuild work out which features to enable or disable based on that to get the fastest and most featureful kernel that still works on all enabled platforms. Arnd