Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 16 Sep 2019 09:12:12 -0700 (PDT)
Subject:     Re: [RFC PATCH 0/2] Add support for SBI version to 0.2
In-Reply-To: <20190916065446.GA6566@infradead.org>
CC:     aou@eecs.berkeley.edu, alankao@andestech.com,
        alexios.zavras@intel.com, anup@brainfault.org,
        Paul Walmsley <paul.walmsley@sifive.com>,
        linux-kernel@vger.kernel.org, rppt@linux.ibm.com,
        Christoph Hellwig <hch@infradead.org>,
        Atish Patra <Atish.Patra@wdc.com>, gary@garyguo.net,
        Greg KH <gregkh@linuxfoundation.org>,
        linux-riscv@lists.infradead.org, tglx@linutronix.de
From:   Palmer Dabbelt <palmer@sifive.com>
To:     Christoph Hellwig <hch@infradead.org>
Message-ID: <mhng-d7823725-b118-4588-bcec-e85354e52283@palmer-si-x1c4>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, 15 Sep 2019 23:54:46 PDT (-0700), Christoph Hellwig wrote:
> On Fri, Sep 13, 2019 at 08:54:27AM -0700, Palmer Dabbelt wrote:
>> On Tue, Sep 3, 2019 at 12:38 AM hch@infradead.org <hch@infradead.org> wrote:
>> 
>> > On Fri, Aug 30, 2019 at 11:13:25PM +0000, Atish Patra wrote:
>> > > If I understood you clearly, you want to call it legacy in the spec and
>> > > just say v0.1 extensions.
>> > > 
>> > > The whole idea of marking them as legacy extensions to indicate that it
>> > > would be obsolete in the future.
>> > > 
>> > > But I am not too worried about the semantics here. So I am fine with
>> > > just changing the text to v0.1 if that avoids confusion.
>> >
>> > So my main problems is that we are lumping all the "legacy" extensions
>> > together.  While some of them are simply a bad idea and shouldn't
>> > really be implemented for anything new ever, others like the sfence.vma
>> > and ipi ones are needed until we have hardware support to avoid them
>> > and possibly forever for virtualization.
>> >
>> > So either we use different markers of legacy for them, or we at least
>> > define new extensions that replace them at the same time.  What I
>> > want to avoid is the possibіly of an implementation using the really
>> > legacy bits and new extensions at the same time.
>> >
>> 
>> Nominally we've got to replace these as well because we didn't include
>> the length of the hart mask. 
>
> Well, let's do that as part of definining the first real post-0.1
> SBI then, and don't bother defining the old ones as legacy at all.
>
> Just two different specs that don't interact except that we reserve
> extension space in the new one for the old one so that one SBI spec
> can implement both.

Makes sense.  We're getting finish with this "just go write everything down" 
exercise, so we can start actually doing things now :).