Uhyve: Speed up serial output

[jounathaen]

• Uhyve: Use the SerialBufferWrite hypercall instead of the Uart hypercall: This reduces the number of serial output related hypercalls by ~3x.

Attention:

• Depends on Use hypercall definitions from uhyve-interface #1393
• Depends on a new Uhyve release that has support for this hypercall (v0.4.0)

[mkroening]

I don't feel good about including heapless since we have come so far without it, but I can't think of anything better. 👍

Regarding the general approach, it would be a lot nicer to have a proper io::BufWriter, but core::io is too far away still. (The most up-to-date approach I could find is wcampbell0x2a/no-std-io2, and even that has issues.

So leaving io::BufWriter aside, it might still be worthwhile to have this buffering strategy take place outside arch such that all serial ports can take advantage of it. For those that can't, the overhead will probably not be too bad, I think. Avoiding the \n check here by extracting this into external flush calls would also be nice sometime in the future when we have nice core::io abstractions.

[jounathaen]

I agree with all your points. Especially, the unification of some IO functions across the architectures is desirable. But I'd still propose to merge this now and enhance later on.

[mkroening]

But I'd still propose to merge this now and enhance later on.

Yeah, sure, but this is blocked on #1393.

[mkroening]

Could you rebase this, since #1393 is merged? :)

[mkroening]

Would it make sense to move this to the arch-independent part Console (src/console.rs#L15-L17)?

That would drastically reduce the code duplication, make the code simpler, and avoid clippy::large_enum_variant. The additional overhead of doing an extra copy for byte-wise serial devices is probably negligible, I'd expect.

[mkroening]

Thanks!

Will merge after the CI on the first commit is green. :)

[mkroening]

The output of the second commit is wrong. I'll look for the new line issue tomorrow.