On Friday, February 14, 2020 at 4:00:49 PM UTC-7, Jan Kiszka wrote:
>
> Well, we need the CR because we are also writing to real UARTs.
Oh, right, I guess I didn't realize that hardware UARTs would need to
explicitly be told to do both a CR and a LF.
> If there
> are tooling issues with the current reverse order (which was simpler to
> implement IIRC), we can flip that
Well, I'm guessing hardware UARTs don't really care what order the CR and
LF come in. So if that’s true, then I think it would be a good idea to
print CR first, since that's what software expects.
> , e.g. like this:
>
> diff --git a/hypervisor/uart.c b/hypervisor/uart.c
> index a43773c2..4f4eba4e 100644
> --- a/hypervisor/uart.c
> +++ b/hypervisor/uart.c
> @@ -19,16 +19,19 @@ struct uart_chip *uart = NULL;
>
> void uart_write(const char *msg)
> {
> - char c = 0;
> + char c, cached_c = 0;
>
> while (1) {
> - if (c == '\n')
> - c = '\r';
> - else
> - c = *msg++;
> + c = cached_c ? : *msg++;
> if (!c)
> break;
>
> + cached_c = 0;
> + if (c == '\n') {
> + cached_c = c;
> + c = '\r';
> + }
> +
> while (uart->is_busy(uart))
> cpu_relax();
> if (panic_in_progress && panic_cpu !=
> phys_processor_id())
>
> Jan
>
I think something like this would be good.
I tried this specific example out, and it completely freezes everything.
Looking at the code closer, once cached_c is set to '\n', I think it
becomes an infinite loop.
Thanks,
-Michael
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/7562e73e-cfc3-4df8-8ce2-8986f903d44b%40googlegroups.com.
