Re: ADC device not allowed multiple opens
Thanks for all the input. I will look at the adc driver in a bit more detail to see which option is best. My original thought was to do what you had done Andrzej: if the device is already opened, just return OK. But I will look at the various locks and such to determine if there will be issues here. Thanks all > On Jun 6, 2018, at 3:17 PM, Andrzej Kaczmarek > wrote: > > Hi, > > +1 for proper ref counting > btw, trng_nrf52 already works this way except it does not check ref > counter explicitly but OS_DEV_F_STATUS_OPEN flag instead. This is also > already used in Mynewt as NimBLE host, controller and TinyCrypt can > (depending on configuration) just open trng device on its own and > there is no need to open it "globally". > > One thing that may need to be fixed though is some locking when > calling open/close handlers since they are now called unlocked and ref > counter is updated later. Since ref counter is checked in these > handlers this may cause device to be initialized more than once and > also to be not un-initialized when all references are dropped. Both > are not a problem for trng_nrf52 driver so I did not worry about it > too much ;-) > > Best, > Andrzej > > > On Wed, Jun 6, 2018 at 10:56 PM will sanfilippo wrote: >> >> Chris and Vipul: >> >> That does indeed seem to be a decent option! I will see if others chime in >> and if not, add that change. >> >> Thanks!!! >> >>> On Jun 6, 2018, at 1:32 PM, Vipul Rahane wrote: >>> >>> On Jun 6, 2018, at 1:01 PM, Christopher Collins wrote: On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote: > Chris: > > I might be missing something here, but given that os_dev already has a > reference count and that handles multiple folks opening/closing the > device, does the underlying adc driver need a reference count itself? If > it just returned no error if opened again this would be fine. > > I do note that os_dev_open() and os_dev_close() always call the > open/close handlers regardless of reference count. I wonder if that > should be changed (meaning only call open/close once)? No, you aren't missing anything; I just misunderstood the os_dev reference counting. Thanks for setting me straight :). Another option: the ADC open function checks its os_dev's reference count. If the value is greater than zero, then return without doing anything. >>> >>> I was going to suggest that as well. Seems like a simple solution :-) >>> Chris > > >> On Jun 6, 2018, at 10:13 AM, Christopher Collins >> wrote: >> >> On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: >>> Hello: >>> >>> I am not the most familiar with the ADC device so it is possible that >>> it was being used incorrectly but in any event I ran across something I >>> wanted to discuss. The call to os_dev_open() allows a device to be >>> opened multiple times (there is a reference count there). However, the >>> call to nrf52_adc_open() returns an error (OS_EBUSY) if the device has >>> already been opened. >>> >>> This presented a problem in the following case: consider two >>> independent packages both of which want to use ADC_0. Each package is >>> going to attempt to open the ADC device (since it has no idea if it was >>> already opened) but the second attempt to open the device will result >>> in an error code returned. Depending on how the code is written in the >>> package, this could be a problem. Given that an ADC is almost always a >>> mutli-channel peripheral (one adc device has multple channels) I would >>> suspect the above case to be common: multiple packages wanting an ADC >>> channel from a single device. >>> >>> I am not sure if anything needs to be done here; just wanted to see if >>> folks thought there should different behavior with regards to the >>> function returning an error if the device was already opened. If not, >>> folks are going to have to be careful when they write code using the >>> adc device. Seems to me if nothing is going to change we have two >>> options: >>> >>> 1) The device gets created and opened in some place and handed to the >>> packages that need it. >>> 2) The device gets created (say by the bsp) and each package can >>> attempt to open the device. If os_dev_lookup() returns !NULL but >>> os_dev_open() returns NULL it means that the device has already been >>> opened. >>> >>> Something about #2 just sort of bothers me. I do not like ambiguous >>> stuff like that; how do you know if there was an error for another >>> reason? >> >> Why not: >> >> 3) Make the ADC driver consistent with other drivers by adding a >> reference count. >> >> ? >> >> I know something less than
Re: ADC device not allowed multiple opens
Hi, +1 for proper ref counting btw, trng_nrf52 already works this way except it does not check ref counter explicitly but OS_DEV_F_STATUS_OPEN flag instead. This is also already used in Mynewt as NimBLE host, controller and TinyCrypt can (depending on configuration) just open trng device on its own and there is no need to open it "globally". One thing that may need to be fixed though is some locking when calling open/close handlers since they are now called unlocked and ref counter is updated later. Since ref counter is checked in these handlers this may cause device to be initialized more than once and also to be not un-initialized when all references are dropped. Both are not a problem for trng_nrf52 driver so I did not worry about it too much ;-) Best, Andrzej On Wed, Jun 6, 2018 at 10:56 PM will sanfilippo wrote: > > Chris and Vipul: > > That does indeed seem to be a decent option! I will see if others chime in > and if not, add that change. > > Thanks!!! > > > On Jun 6, 2018, at 1:32 PM, Vipul Rahane wrote: > > > > > >> On Jun 6, 2018, at 1:01 PM, Christopher Collins wrote: > >> > >> On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote: > >>> Chris: > >>> > >>> I might be missing something here, but given that os_dev already has a > >>> reference count and that handles multiple folks opening/closing the > >>> device, does the underlying adc driver need a reference count itself? If > >>> it just returned no error if opened again this would be fine. > >>> > >>> I do note that os_dev_open() and os_dev_close() always call the > >>> open/close handlers regardless of reference count. I wonder if that > >>> should be changed (meaning only call open/close once)? > >> > >> No, you aren't missing anything; I just misunderstood the os_dev > >> reference counting. Thanks for setting me straight :). > >> > >> Another option: the ADC open function checks its os_dev's reference > >> count. If the value is greater than zero, then return without doing > >> anything. > >> > > > > I was going to suggest that as well. Seems like a simple solution :-) > > > >> Chris > >> > >>> > >>> > On Jun 6, 2018, at 10:13 AM, Christopher Collins > wrote: > > On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: > > Hello: > > > > I am not the most familiar with the ADC device so it is possible that > > it was being used incorrectly but in any event I ran across something I > > wanted to discuss. The call to os_dev_open() allows a device to be > > opened multiple times (there is a reference count there). However, the > > call to nrf52_adc_open() returns an error (OS_EBUSY) if the device has > > already been opened. > > > > This presented a problem in the following case: consider two > > independent packages both of which want to use ADC_0. Each package is > > going to attempt to open the ADC device (since it has no idea if it was > > already opened) but the second attempt to open the device will result > > in an error code returned. Depending on how the code is written in the > > package, this could be a problem. Given that an ADC is almost always a > > mutli-channel peripheral (one adc device has multple channels) I would > > suspect the above case to be common: multiple packages wanting an ADC > > channel from a single device. > > > > I am not sure if anything needs to be done here; just wanted to see if > > folks thought there should different behavior with regards to the > > function returning an error if the device was already opened. If not, > > folks are going to have to be careful when they write code using the > > adc device. Seems to me if nothing is going to change we have two > > options: > > > > 1) The device gets created and opened in some place and handed to the > > packages that need it. > > 2) The device gets created (say by the bsp) and each package can > > attempt to open the device. If os_dev_lookup() returns !NULL but > > os_dev_open() returns NULL it means that the device has already been > > opened. > > > > Something about #2 just sort of bothers me. I do not like ambiguous > > stuff like that; how do you know if there was an error for another > > reason? > > Why not: > > 3) Make the ADC driver consistent with other drivers by adding a > reference count. > > ? > > I know something less than nothing about the ADC code, so I could > certainly be missing something. > > Chris > >>> > > > > - Vipul >
Re: ADC device not allowed multiple opens
Chris and Vipul: That does indeed seem to be a decent option! I will see if others chime in and if not, add that change. Thanks!!! > On Jun 6, 2018, at 1:32 PM, Vipul Rahane wrote: > > >> On Jun 6, 2018, at 1:01 PM, Christopher Collins wrote: >> >> On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote: >>> Chris: >>> >>> I might be missing something here, but given that os_dev already has a >>> reference count and that handles multiple folks opening/closing the device, >>> does the underlying adc driver need a reference count itself? If it just >>> returned no error if opened again this would be fine. >>> >>> I do note that os_dev_open() and os_dev_close() always call the open/close >>> handlers regardless of reference count. I wonder if that should be changed >>> (meaning only call open/close once)? >> >> No, you aren't missing anything; I just misunderstood the os_dev >> reference counting. Thanks for setting me straight :). >> >> Another option: the ADC open function checks its os_dev's reference >> count. If the value is greater than zero, then return without doing >> anything. >> > > I was going to suggest that as well. Seems like a simple solution :-) > >> Chris >> >>> >>> On Jun 6, 2018, at 10:13 AM, Christopher Collins wrote: On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: > Hello: > > I am not the most familiar with the ADC device so it is possible that it > was being used incorrectly but in any event I ran across something I > wanted to discuss. The call to os_dev_open() allows a device to be opened > multiple times (there is a reference count there). However, the call to > nrf52_adc_open() returns an error (OS_EBUSY) if the device has already > been opened. > > This presented a problem in the following case: consider two independent > packages both of which want to use ADC_0. Each package is going to > attempt to open the ADC device (since it has no idea if it was already > opened) but the second attempt to open the device will result in an error > code returned. Depending on how the code is written in the package, this > could be a problem. Given that an ADC is almost always a mutli-channel > peripheral (one adc device has multple channels) I would suspect the > above case to be common: multiple packages wanting an ADC channel from a > single device. > > I am not sure if anything needs to be done here; just wanted to see if > folks thought there should different behavior with regards to the > function returning an error if the device was already opened. If not, > folks are going to have to be careful when they write code using the adc > device. Seems to me if nothing is going to change we have two options: > > 1) The device gets created and opened in some place and handed to the > packages that need it. > 2) The device gets created (say by the bsp) and each package can attempt > to open the device. If os_dev_lookup() returns !NULL but os_dev_open() > returns NULL it means that the device has already been opened. > > Something about #2 just sort of bothers me. I do not like ambiguous stuff > like that; how do you know if there was an error for another reason? Why not: 3) Make the ADC driver consistent with other drivers by adding a reference count. ? I know something less than nothing about the ADC code, so I could certainly be missing something. Chris >>> > > - Vipul
Re: ADC device not allowed multiple opens
> On Jun 6, 2018, at 1:01 PM, Christopher Collins wrote: > > On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote: >> Chris: >> >> I might be missing something here, but given that os_dev already has a >> reference count and that handles multiple folks opening/closing the device, >> does the underlying adc driver need a reference count itself? If it just >> returned no error if opened again this would be fine. >> >> I do note that os_dev_open() and os_dev_close() always call the open/close >> handlers regardless of reference count. I wonder if that should be changed >> (meaning only call open/close once)? > > No, you aren't missing anything; I just misunderstood the os_dev > reference counting. Thanks for setting me straight :). > > Another option: the ADC open function checks its os_dev's reference > count. If the value is greater than zero, then return without doing > anything. > I was going to suggest that as well. Seems like a simple solution :-) > Chris > >> >> >>> On Jun 6, 2018, at 10:13 AM, Christopher Collins wrote: >>> >>> On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: Hello: I am not the most familiar with the ADC device so it is possible that it was being used incorrectly but in any event I ran across something I wanted to discuss. The call to os_dev_open() allows a device to be opened multiple times (there is a reference count there). However, the call to nrf52_adc_open() returns an error (OS_EBUSY) if the device has already been opened. This presented a problem in the following case: consider two independent packages both of which want to use ADC_0. Each package is going to attempt to open the ADC device (since it has no idea if it was already opened) but the second attempt to open the device will result in an error code returned. Depending on how the code is written in the package, this could be a problem. Given that an ADC is almost always a mutli-channel peripheral (one adc device has multple channels) I would suspect the above case to be common: multiple packages wanting an ADC channel from a single device. I am not sure if anything needs to be done here; just wanted to see if folks thought there should different behavior with regards to the function returning an error if the device was already opened. If not, folks are going to have to be careful when they write code using the adc device. Seems to me if nothing is going to change we have two options: 1) The device gets created and opened in some place and handed to the packages that need it. 2) The device gets created (say by the bsp) and each package can attempt to open the device. If os_dev_lookup() returns !NULL but os_dev_open() returns NULL it means that the device has already been opened. Something about #2 just sort of bothers me. I do not like ambiguous stuff like that; how do you know if there was an error for another reason? >>> >>> Why not: >>> >>> 3) Make the ADC driver consistent with other drivers by adding a >>> reference count. >>> >>> ? >>> >>> I know something less than nothing about the ADC code, so I could >>> certainly be missing something. >>> >>> Chris >> - Vipul
Re: ADC device not allowed multiple opens
On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote: > Chris: > > I might be missing something here, but given that os_dev already has a > reference count and that handles multiple folks opening/closing the device, > does the underlying adc driver need a reference count itself? If it just > returned no error if opened again this would be fine. > > I do note that os_dev_open() and os_dev_close() always call the open/close > handlers regardless of reference count. I wonder if that should be changed > (meaning only call open/close once)? No, you aren't missing anything; I just misunderstood the os_dev reference counting. Thanks for setting me straight :). Another option: the ADC open function checks its os_dev's reference count. If the value is greater than zero, then return without doing anything. Chris > > > > On Jun 6, 2018, at 10:13 AM, Christopher Collins wrote: > > > > On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: > >> Hello: > >> > >> I am not the most familiar with the ADC device so it is possible that it > >> was being used incorrectly but in any event I ran across something I > >> wanted to discuss. The call to os_dev_open() allows a device to be opened > >> multiple times (there is a reference count there). However, the call to > >> nrf52_adc_open() returns an error (OS_EBUSY) if the device has already > >> been opened. > >> > >> This presented a problem in the following case: consider two independent > >> packages both of which want to use ADC_0. Each package is going to attempt > >> to open the ADC device (since it has no idea if it was already opened) but > >> the second attempt to open the device will result in an error code > >> returned. Depending on how the code is written in the package, this could > >> be a problem. Given that an ADC is almost always a mutli-channel > >> peripheral (one adc device has multple channels) I would suspect the above > >> case to be common: multiple packages wanting an ADC channel from a single > >> device. > >> > >> I am not sure if anything needs to be done here; just wanted to see if > >> folks thought there should different behavior with regards to the function > >> returning an error if the device was already opened. If not, folks are > >> going to have to be careful when they write code using the adc device. > >> Seems to me if nothing is going to change we have two options: > >> > >> 1) The device gets created and opened in some place and handed to the > >> packages that need it. > >> 2) The device gets created (say by the bsp) and each package can attempt > >> to open the device. If os_dev_lookup() returns !NULL but os_dev_open() > >> returns NULL it means that the device has already been opened. > >> > >> Something about #2 just sort of bothers me. I do not like ambiguous stuff > >> like that; how do you know if there was an error for another reason? > > > > Why not: > > > > 3) Make the ADC driver consistent with other drivers by adding a > > reference count. > > > > ? > > > > I know something less than nothing about the ADC code, so I could > > certainly be missing something. > > > > Chris >
[DISCUSS] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1
Hi all, This thread is for any and all discussion regarding the release of Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0. All feedback is welcome. -- pozdrawiam Szymon Janc
[VOTE] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1
Hello all, I am pleased to be calling this vote for the source release of Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0. Apache Mynewt is a community-driven, permissively licensed open source initiative for constrained, embedded applications. Mynewt provides a real-time operating system, flash file system, network stacks, and support utilities for real-world embedded systems. NimBLE is having its first release as separate package. This is first and last release that is coordinated with Apache Mynewt release. After that NimBLE will follow with independent releases. For full release notes, please visit the Apache Mynewt Wiki: https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes This release candidate was tested as follows: 1. Manual execution of the Mynewt test plan: https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test +Plan The test results can be found at: https://cwiki.apache.org/confluence/display/MYNEWT/1.4.0+Test+Results Note that this testing is not yet complete and more results will show while voting is ongoing. 2. The full unit test suite for this release was executed via "newt test all" with no failures. This testing was performed on the following platforms: * OS X 10.13 * Ubuntu Linux 18.04 The release candidate to be voted on is available at: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/ The commits under consideration are as follows: blinky: repos: https://github.com/apache/mynewt-blinky commit ceecdd3c98bba50859d744ce17b9e8f8b5206dd2 core: repos: https://github.com/apache/mynewt-core commit ddaf6d822f385b546fac683191ce776ccd53485a newt: repos: https://github.com/apache/mynewt-newt commit bae15edb3b1b8f891f169fe9793131df91fb236b newtmgr: repos: https://github.com/apache/mynewt-newtmgr commit 5c759c31de25ec078f903a856d19c3ec1ecea28b nimble: repos: https://github.com/apache/mynewt-nimble commit a85b65d97ecd062d8ea88c1a151f649e35e47420 In addition, the following newt convenience binaries are available: linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/ rc1/apache-mynewt-newt-bin-linux-1.4.0.tgz osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/ apache-mynewt-newt-bin-osx-1.4.0.tgz The release candidate is signed with a GPG key available at: https://dist.apache.org/repos/dist/dev/mynewt/KEYS The vote is open for at least 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package [ ] 0 I don't feel strongly about it, but don't object [ ] -1 Do not release this package because... Anyone can participate in testing and voting, not just committers, please feel free to try out the release candidate and provide your votes. A separate [DISCUSS] thread will be opened to talk about this release candidate. -- pozdrawiam Szymon Janc
Re: ADC device not allowed multiple opens
Chris: I might be missing something here, but given that os_dev already has a reference count and that handles multiple folks opening/closing the device, does the underlying adc driver need a reference count itself? If it just returned no error if opened again this would be fine. I do note that os_dev_open() and os_dev_close() always call the open/close handlers regardless of reference count. I wonder if that should be changed (meaning only call open/close once)? > On Jun 6, 2018, at 10:13 AM, Christopher Collins wrote: > > On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: >> Hello: >> >> I am not the most familiar with the ADC device so it is possible that it was >> being used incorrectly but in any event I ran across something I wanted to >> discuss. The call to os_dev_open() allows a device to be opened multiple >> times (there is a reference count there). However, the call to >> nrf52_adc_open() returns an error (OS_EBUSY) if the device has already been >> opened. >> >> This presented a problem in the following case: consider two independent >> packages both of which want to use ADC_0. Each package is going to attempt >> to open the ADC device (since it has no idea if it was already opened) but >> the second attempt to open the device will result in an error code returned. >> Depending on how the code is written in the package, this could be a >> problem. Given that an ADC is almost always a mutli-channel peripheral (one >> adc device has multple channels) I would suspect the above case to be >> common: multiple packages wanting an ADC channel from a single device. >> >> I am not sure if anything needs to be done here; just wanted to see if folks >> thought there should different behavior with regards to the function >> returning an error if the device was already opened. If not, folks are going >> to have to be careful when they write code using the adc device. Seems to me >> if nothing is going to change we have two options: >> >> 1) The device gets created and opened in some place and handed to the >> packages that need it. >> 2) The device gets created (say by the bsp) and each package can attempt to >> open the device. If os_dev_lookup() returns !NULL but os_dev_open() returns >> NULL it means that the device has already been opened. >> >> Something about #2 just sort of bothers me. I do not like ambiguous stuff >> like that; how do you know if there was an error for another reason? > > Why not: > > 3) Make the ADC driver consistent with other drivers by adding a > reference count. > > ? > > I know something less than nothing about the ADC code, so I could > certainly be missing something. > > Chris
FINAL REMINDER: Apache EU Roadshow 2018 in Berlin next week!
Hello Apache Supporters and Enthusiasts This is a final reminder that our Apache EU Roadshow will be held in Berlin next week on 13th and 14th June 2018. We will have 28 different sessions running over 2 days that cover some great topics. So if you are interested in Microservices, Internet of Things (IoT), Cloud, Apache Tomcat or Apache Http Server then we have something for you. https://foss-backstage.de/sessions/apache-roadshow We will be co-located with FOSS Backstage, so if you are interested in topics such as incubator, the Apache Way, open source governance, legal, trademarks or simply open source communities then there will be something there for you too. You can attend any of talks, presentations and workshops from the Apache EU Roadshow or FOSS Backstage. You can find details of the combined Apache EU Roadshow and FOSS Backstage conference schedule below: https://foss-backstage.de/schedule?day=2018-06-13 Ticket prices go up on 8th June 2018 and we have a last minute discount code that anyone can use before the deadline: 15% discount code: ASF15_discount valid until June 7, 23:55 CET You can register at the following link: https://foss-backstage.de/tickets Our Apache booth and lounge will be open from 11th - 14th June for meetups, hacking or to simply relax between sessions. And we will be posting regular updates on social media throughout next week so please follow us on Twitter @ApacheCon Thank you for your continued support and we look forward to seeing you in Berlin! Thanks Sharan Foga, VP Apache Community Development http://apachecon.com/ PLEASE NOTE: You are receiving this message because you are subscribed to a user@ or dev@ list of one or more Apache Software Foundation projects.
Re: ADC device not allowed multiple opens
On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote: > Hello: > > I am not the most familiar with the ADC device so it is possible that it was > being used incorrectly but in any event I ran across something I wanted to > discuss. The call to os_dev_open() allows a device to be opened multiple > times (there is a reference count there). However, the call to > nrf52_adc_open() returns an error (OS_EBUSY) if the device has already been > opened. > > This presented a problem in the following case: consider two independent > packages both of which want to use ADC_0. Each package is going to attempt to > open the ADC device (since it has no idea if it was already opened) but the > second attempt to open the device will result in an error code returned. > Depending on how the code is written in the package, this could be a problem. > Given that an ADC is almost always a mutli-channel peripheral (one adc device > has multple channels) I would suspect the above case to be common: multiple > packages wanting an ADC channel from a single device. > > I am not sure if anything needs to be done here; just wanted to see if folks > thought there should different behavior with regards to the function > returning an error if the device was already opened. If not, folks are going > to have to be careful when they write code using the adc device. Seems to me > if nothing is going to change we have two options: > > 1) The device gets created and opened in some place and handed to the > packages that need it. > 2) The device gets created (say by the bsp) and each package can attempt to > open the device. If os_dev_lookup() returns !NULL but os_dev_open() returns > NULL it means that the device has already been opened. > > Something about #2 just sort of bothers me. I do not like ambiguous stuff > like that; how do you know if there was an error for another reason? Why not: 3) Make the ADC driver consistent with other drivers by adding a reference count. ? I know something less than nothing about the ADC code, so I could certainly be missing something. Chris
ADC device not allowed multiple opens
Hello: I am not the most familiar with the ADC device so it is possible that it was being used incorrectly but in any event I ran across something I wanted to discuss. The call to os_dev_open() allows a device to be opened multiple times (there is a reference count there). However, the call to nrf52_adc_open() returns an error (OS_EBUSY) if the device has already been opened. This presented a problem in the following case: consider two independent packages both of which want to use ADC_0. Each package is going to attempt to open the ADC device (since it has no idea if it was already opened) but the second attempt to open the device will result in an error code returned. Depending on how the code is written in the package, this could be a problem. Given that an ADC is almost always a mutli-channel peripheral (one adc device has multple channels) I would suspect the above case to be common: multiple packages wanting an ADC channel from a single device. I am not sure if anything needs to be done here; just wanted to see if folks thought there should different behavior with regards to the function returning an error if the device was already opened. If not, folks are going to have to be careful when they write code using the adc device. Seems to me if nothing is going to change we have two options: 1) The device gets created and opened in some place and handed to the packages that need it. 2) The device gets created (say by the bsp) and each package can attempt to open the device. If os_dev_lookup() returns !NULL but os_dev_open() returns NULL it means that the device has already been opened. Something about #2 just sort of bothers me. I do not like ambiguous stuff like that; how do you know if there was an error for another reason? Thoughts/comments/suggestions greatly appreciated!
