> 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. 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. 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.
