On 15.02.20 00:51, Michael Hinton wrote:
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 thatWell, 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.
Yeah, was nonsense. The version in next is better. Jan -- 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/05da8dd6-13c2-ea3a-b91b-3fb4e5114238%40web.de.
