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

[Palmer Dabbelt]

On Thu, 10 Mar 2022 05:37:27 PST (-0800), Michael at MichaelKloos.com wrote:
> Is there something I can do that would help alleviate your concerns or
> apprehension?

IMO this is one of those cases where having hardware is required.

I can understand the goal of providing a Linux port for the minimal 
RISC-V compatible system, but IIUC the minimal RISC-V compatible system 
is any object associated with a member of the RISC-V foundation that 
said member attests is a RISC-V system.  There's really no way to 
implement Linux on all such systems so we have to set the bar somewhere, 
and bar is generally set at "more time will be spent using this than 
maintaining it".  Systems without M have generally not met that bar, and 
I don't see anything changing now.

If you have users then I'm happy to reconsider, the goal here is to make 
real systems work.  That said: we've already got enough trouble trying 
to make actual shipping hardware function correctly, we're all going to 
lose our minds trying to chase around everything that could in theory be 
a RISC-V system but doesn't actually exist.

>
> On 3/10/2022 8:22 AM, Michael T. Kloos wrote:
>
>> Some other thoughts:
>> It sounds like I am not the first person to want this feature and I
>> probably won't be the last.  I created the change for my own reasons, the
>> same as any other contributor.  I think we all know that I can not pull
>> out some chart and say, "This many people want this and here is why."  I
>> live in central Ohio and have been doing this as a hobby.  I don't even
>> know anyone else who knows about systems and operating system development.
>> If the justification that you are looking for is that I as some
>> hypothetical developer at a major tech company is about to release a new
>> RISC-V chip without M support but we want it to run Linux, I can not
>> provide that answer.  It sounds a bit like some software or hardware,
>> chicken or the egg anyway.  Trying to maintain my own fork if people
>> start contributing patches with incompatible assembly scares me.
>>      Michael