Messages in this thread | | | Date | Wed, 09 Mar 2022 23:34:27 -0800 (PST) | Subject | Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension | From | 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@michaelkloos.com> 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@michaelkloos.com> > > 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
| |