Re: [RFC PATCH 0/2] Add support for SBI version to 0.2

[Atish Patra]

On Thu, 2019-08-29 at 03:59 -0700, hch@xxxxxxxxxxxxx wrote:
> On Tue, Aug 27, 2019 at 10:19:42PM +0000, Atish Patra wrote:
> > I did not understand this part. All the legacy SBI calls are
> > defined as
> > a separate extension ID not single extension. How did it break the
> > backward compatibility ?
> 
> Yes, sorry I mistead this.  The way is is defined is rather
> non-intuitive, but actually backwards compatible.
> 
> > I think the confusion is because of legacy renaming. They are not
> > single legacy extension. They are all separate extensions. The spec
> > just called all those extensions as collectively as legacy. So I
> > just
> > tried to make the patch sync with the spec.
> > 
> > If that's the source of confusion, I can rename it to sbi_0.1_x in
> > stead of legacy.
> 
> I think we actually need to fix the spec instead, even if it just the
> naming and not the mechanism.
> 

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.

> > >  (1) actually board specific and have not place in a cpu
> > > abstraction
> > >      layer: getchar/putchar, these should just never be
> > > advertised in
> > > a
> > >       non-legacy setup, and the drivers using them should not
> > > probe
> > >       on a sbi 0.2+ system
> > 
> > In that case, we have to update the drivers(earlycon-riscv-sbi &
> > hvc_riscv_sbi) in kernel as well. Once these patches are merged,
> > nobody
> > will be able to use earlycon=sbi feature in mainline kernel.
> > 
> > Personally, I am fine with it. But there were some interest during
> > RISC-V workshop in keeping these for now for easy debugging and
> > early
> > bringup.
> 
> The getchar/putchar calls unfortunately are fundamentally flawed, as
> they mean the sbi can still access the console after the host has
> taken
> it over using its own drivers.  Which will lead to bugs sooner or
> later.
> 
> And if you can bring up a console driver in opensbi it should be just
> as trivial to bring up the kernel version.

-- 
Regards,
Atish