linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "hch@infradead.org" <hch@infradead.org>
To: Palmer Dabbelt <palmer@sifive.com>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Atish Patra <Atish.Patra@wdc.com>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"alankao@andestech.com" <alankao@andestech.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"anup@brainfault.org" <anup@brainfault.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rppt@linux.ibm.com" <rppt@linux.ibm.com>,
	"alexios.zavras@intel.com" <alexios.zavras@intel.com>,
	"gary@garyguo.net" <gary@garyguo.net>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC PATCH 0/2] Add support for SBI version to 0.2
Date: Sun, 15 Sep 2019 23:54:46 -0700	[thread overview]
Message-ID: <20190916065446.GA6566@infradead.org> (raw)
In-Reply-To: <CANs6eMmcbtJ5KTU00LpfTtXszsdi1Jem_5j6GWO+8Yo3JnvTqg@mail.gmail.com>

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.

  parent reply	other threads:[~2019-09-16  6:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 23:32 [RFC PATCH 0/2] Add support for SBI version to 0.2 Atish Patra
2019-08-26 23:32 ` [RFC PATCH 1/2] RISC-V: Mark existing SBI as legacy SBI Atish Patra
2019-08-27  7:51   ` Mike Rapoport
2019-08-27  8:28     ` Anup Patel
2019-08-27  8:37       ` Mike Rapoport
2019-08-28 21:37         ` Palmer Dabbelt
2019-08-27 20:34     ` Atish Patra
2019-08-27 14:03   ` Christoph Hellwig
2019-08-27 14:04     ` Christoph Hellwig
2019-08-27 20:37     ` Atish Patra
2019-08-29 10:56       ` hch
2019-08-26 23:32 ` [RFC PATCH 2/2] RISC-V: Add basic support for SBI v0.2 Atish Patra
2019-08-27  7:58   ` Mike Rapoport
2019-08-27  8:23     ` Anup Patel
2019-08-27  8:39       ` Mike Rapoport
2019-08-27  9:28         ` Anup Patel
2019-08-27 20:30         ` Atish Patra
2019-08-27  9:36   ` Anup Patel
2019-08-27 20:43     ` Atish Patra
2019-08-27 14:11   ` Christoph Hellwig
2019-08-27 14:46 ` [RFC PATCH 0/2] Add support for SBI version to 0.2 Christoph Hellwig
2019-08-27 22:19   ` Atish Patra
2019-08-29 10:59     ` hch
2019-08-30 23:13       ` Atish Patra
2019-09-03  7:38         ` hch
     [not found]           ` <CANs6eMmcbtJ5KTU00LpfTtXszsdi1Jem_5j6GWO+8Yo3JnvTqg@mail.gmail.com>
2019-09-16  6:54             ` hch [this message]
2019-09-16 16:12               ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190916065446.GA6566@infradead.org \
    --to=hch@infradead.org \
    --cc=Atish.Patra@wdc.com \
    --cc=alankao@andestech.com \
    --cc=alexios.zavras@intel.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@linux.ibm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).