It would be interesting to hear if folks want to do nested open/close… I think it a good thing to know the driver was opened/closed reliably but I was not thinking there would be nested open/closes but I could see why some folks might want that… rest seems fine to me.
> On Sep 10, 2016, at 11:27 AM, Sterling Hughes <[email protected]> wrote: > > 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
