On Thu, 2 Jun 2022, Greg Favor wrote:

On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini <stefano.stabellini@...> wrote:
On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote:
> Of course a console is needed. But I was questioning the need for something much
> more elaborate than a putchar/getchar interface. I understand its needed to port
> the hypervisor but I undersatnd it would be needed for very early parts of the
> hypervisor where it does not even have the ability to master a uart on its own.

Yeah, I think you are right that it is not a must-have feature but a
nice-to-have feature.


Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who
cares how fast or slow is boot time, in the past I have found that to be a risky presumption in certain production environments where boot
time matters (especially with frequent standing up of VMs from scratch).  So a worthwhile sanity check question would be 1) what percentage
of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage
inflate due to SBI calls for every individual character.

The numbers you asked will help but I just wanted to add that in my
opinion a per-character putchar interface is not suitable for production
due to the reasons you mentioned. I would compile it out in non-DEBUG
builds.

On the other hand the per-string print interface might be usable in
production, even not just early boot. However, of course, a proper UART
driver would be even better.

This is why I think it is nice to have: it expands the potential uses of
the SBI console interface, and it is simple and easy to use. At the same
time it is not a must-have because you could get away with just putchat
in early boot for DEBUG builds, and nothing + UART driver in non-DEBUG
builds.

That is why I am in favor of this addition, although I recognize it is
not critical.