On 25.02.2016 10:05, Daniel Baluta wrote: > > > On 24.02.2016 21:43, Alison Schofield wrote: >> Daniel, >> >> I'm working on IIO coding task #2. >> >> In 'auditing IIO device state updates to locking' I believe that >> in addition to "Updates to state changes must always take mlock", >> any checks of device state must also take mlock. And that is, >> what you are asking us to do in this task. >> (iio_buffer_enabled is checking device state, not setting) >> >> Basically, anywhere iio_dev->currentmode is set|checked use mlock. >> >> Right track? > Correct. > >> For this task, I'm not clear on why we are doing RFC. In practice, >> mlock is used very consistently for protecting device state. >> Can you clarify the controversial aspect? > As agreed on this thread: > http://www.spinics.net/lists/linux-iio/msg18540.html > we will try to propose some API like: > > /iio_device_claim_direct_mode //iio_device_release_direct_mode/ > > which will try to make code easier to read and hide the inner details > of taking/releasing mlock. > > We will make this in two steps: > > * introduce API > * find a place where locking is not done > * use new API > > After IIO maintainer says this is OK: > * update all places with the new API. > > thanks, > Daniel.