Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Sender: michael@michaelkloos.com
Message-ID: <e880a9421239e388ebce74f3cd41637886930f03.camel@michaelkloos.com>
Subject: Re: [PATCH] riscv: Work to remove kernel dependence on the
 M-extension
From:   "Michael T. Kloos" <michael@michaelkloos.com>
To:     Palmer Dabbelt <palmer@dabbelt.com>
Cc:     Christoph Hellwig <hch@infradead.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
Date:   Thu, 10 Mar 2022 23:54:24 -0500
In-Reply-To: <mhng-97bc7422-36da-436a-a326-1705ef6fcace@palmer-ri-x1c9>
References: <mhng-97bc7422-36da-436a-a326-1705ef6fcace@palmer-ri-x1c9>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Well at least I can take some satisfaction in that it seems that on my
2nd patch sent to the Linux kernel, I got it right the first time.  No
one has complained about problems with the code itself, just that they
don't want the feature.  I have also received no errors back from the
build bot.

For now, I will try to maintain this port on my own.  Thank you for the
consideration Palmer.

	Michael

On Thu, 2022-03-10 at 20:29 -0800, Palmer Dabbelt wrote:
> 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