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

Palmer Dabbelt
2022-03-11T04:29:50Z

On Thu, 10 Mar 2022 05:37:27 PST (-0800), Michael@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