Hi Gordon,
This is absolutely true. Essentially, if two tasks are running, and
both write to the console, the characters that get written are in a
different order -- the console is not locked for the duration of
console_write().
The fix here would either to be:
- Allow for multiple console ports and allocate a different one for
newtmgr.
This has the limitation that on real hardware you're going to have to
use 2 UARTs, one for console, one for newtmgr. Now this is probably not
a huge deal, because newtmgr will likely be going over Bluetooth on real
hardware, but it's not ideal either.
- Allow for mutex protection around console_write(), and block between
multiple tasks calling to the console. NLIP can handle interleaved
data, between calls to console_write(). (*)
The downside here is that calls to console_write() will block. So if
you have a higher priority task that wants to write data to the console,
it will have to wait for the lower priority task to finish writing
before executing. These are 128-byte writes.
I'd like to get others thoughts on which of these we should implement.
I'm leaning towards #2 because it feels more write in the operation of
how the console should work. But if it horrifies people to slow down
higher priority tasks because of console writes, I could be convinced
otherwise.
Sterling
(*) Quick NLIP (Newtmgr Line Interface Protocol) primer:
nlip was designed so that it can be interleaved with console reads &
writes, but it does need a guarantee that data won't be inserted within
the context of a line. As a quick primer, the protocol works as such:
0x06 0x09 [2 bytes total *decoded* pkt len] [base 64 encoded data] \n
Data then gets streamed to console_write(), where the maximum number of
bytes tx'd is equal to the size of console_write()'s buffer (currently
128.) If the total packet length is larger then this buffer, then
continuation lines get inserted, which have the following format:
0x04 0x20 [base 64 encoded data] \n
This is streamed out to the console until there is no more data to send.
On 2/26/16 3:58 PM, Gordon Chaffee wrote:
I ran into an issue with log messages and the nlip protocol when
communicating between newtmgr and a sim target. If a log message occurs
after the request is made but before the response is written, it causes the
stream to get out of sync, and newtmgr is unable to parse the response
since it expects a json response.
In my case, I ran into it while adding a 'logs append <msg>' command to
test the logging facility, so the log message is written to the console and
interrupts the nlip stream 100% of the time. Outside of the specific case
I've run into, I think a context switch to another task that writes a log
message could interrupt any message exchange.
Is my thinking correct about the potential problems of log messages being
written to console?
Thanks,
Gordon
