Messages in this thread | | | Date | Mon, 16 Sep 2019 09:12:12 -0700 (PDT) | Subject | Re: [RFC PATCH 0/2] Add support for SBI version to 0.2 | From | Palmer Dabbelt <> |
| |
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 :).
| |