OS device locking

[Sterling Hughes <st...@apache.org>]

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

Re: OS device locking

[will sanfilippo <wi...@runtime.io>]

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 <st...@apache.org> 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