On 2/26/16 6:53 PM, marko kiiskila wrote:
On Feb 26, 2016, at 4:35 PM, Sterling Hughes <[email protected]> wrote:
- 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 should add, this behavior could be optional. For people who don't really
care, or want to allocate newtmgr it's own console, they could do so. For
people who do care, they could turn on console write locking...
Anyhow, I've said enough: thoughts? :-)
Newtmgr protocol was meant to take different data path than
the console (i.e. Bluetooth/IP), and running it over serial was
a bit of stopgap until that’s possible.
Yes, although I think you will want to run newtmgr over console or
serial port as well. For example: how do you do firmware upgrade to a
device without newtmgr?
Given that, I’m not a big fan of adding locking to console.
If the use case is just with simulator, I’d rather just allocate another
serial port. Ptys are cheap.
If it were just SIM, I totally agree.
On the other hand, if the thought is that users will be running this
on real systems, we need a lock here. But in that case there
also needs to be a lockless path to serial port as well, as the system
outputs it’s state in case of assert()/fault, and these cases cannot
wait for lock.
+1
Sterling
