For reference, the OS device code in sterly_refactor:
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/libs/os/src/os_dev.c
I wanted to document my assumptions on OS device locking for folks, and
get input as to whether people agree/disagree that this is the right
approach.
Assumptions:
- Devices are only created _prior_ to the OS running, and devices are
_never_ deleted once being created. Therefore, the OS device list
itself does not need to be locked, as it is immutable during system
operation.
- Open & close call the per-device handlers, and those handlers perform
locking if they view it as necessary. An example of a handler that
locks:
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/drivers/adc/adc_nrf52/src/adc_nrf52.c
(nrf52_adc_open() - line 96.)
- Currently UNSAFE: in cases where locks don’t occur on the device,
OS_DEV_STATUS_OPEN is set and released by open and close, without any
locking. This means that they can’t be called from multiple task
contexts.
- I’m wondering if this should be a reference count, for the cases
where multiple opens & closes are allowed, that way the system always
knows if the driver is opened reliably.
- Suspend & resume (TBC - description here), will not look to acquire a
lock when suspending a device, but rather its up to the driver
implementation to wait for any locks, or provide any housekeeping
regarding the driver itself. Suspend/resume are meant to be called
outside of the context with which a driver is being used.
- Suspend & resume are ONLY going to be called on OPEN drivers.
Sterling
