Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

[Palmer Dabbelt]

On Wed, 09 Mar 2022 02:02:27 PST (-0800), Arnd Bergmann wrote:
> On Wed, Mar 9, 2022 at 6:28 AM Michael T. Kloos
> <michael@xxxxxxxxxxxxxxxx> wrote:
> > Added a new config symbol RISCV_ISA_M to enable the usage of the
> > multiplication, division, and remainder (modulus) instructions
> > from the M-extension.  This configures the march build flag to
> > either include or omit it.
> >
> > I didn't find any assembly using any of the instructions from
> > the M-extension.  However, the BPF JIT is a complicating factor.
> > Currently, it emits M-extension instructions to implement various
> > BPF operations.  For now, I have made HAVE_EBPF_JIT depend on
> > CONFIG_RISCV_ISA_M.
> >
> > I have added the supplementary integer arithmetic functions in
> > the file "arch/riscv/lib/ext_m_supplement.c".  All the code
> > contained in this file is wrapped in an ifndef contingent on the
> > presence of CONFIG_RISCV_ISA_M.
> >
> > Signed-off-by: Michael T. Kloos <michael@xxxxxxxxxxxxxxxx>
>
> The patch looks fine to me, but I increasingly get the feeling that the
> entire platform feature selection in Kconfig should be guarded with
> a global flag that switches between "fully generic" and "fully custom"
> builds, where the generic kernel assumes that all the standard
> features (64-bit, C, M, FPU, MMU, UEFI, ...) are present, the
> incompatible options (XIP, PHYS_RAM_BASE_FIXED,
> CMDLINE_FORCE, BUILTIN_DTB, ...) are force-disabled,
> and all optional features (V/B/P/H extensions, custom instructions,
> platform specific device drivers, ...) are runtime detected.

That'd be wonderful, but unfortunately we're trending the other way -- 
we're at the point where "words in the specification have meaning" is 
controversial, so trying to talk about which flavors of the 
specification are standard is just meaningless.  I obviously hope that 
gets sorted out, as we've clearly been pointed straight off a cliff for 
a while now, but LMKL isn't the place to have that discussion.  We've 
all seen this before, nobody needs to be convinced this leads to a mess.

Until we get to the point where "I wrote 'RISC-V' on that potato I found 
in my couch" can be conclusively determined not compliant with the spec, 
it's just silly to try and talk about what is.

> At the moment, those three types are listed at the same level,
> which gives the impression that they can be freely mixed.
>
>          Arnd