IIO Coding Task 2 ?

IIO Coding Task 2 ?

[Alison Schofield]

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?

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?

Thanks!
alisons

Re: IIO Coding Task 2 ?

[Daniel Baluta]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

<resending answer due to outreachy-kernel delivery failure>

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.


[-- Attachment #2: Type: text/html, Size: 2367 bytes --]

Re: IIO Coding Task 2 ?

[Alison Schofield]

On Thu, Feb 25, 2016 at 10:55:56AM +0200, Daniel Baluta wrote:
> <resending answer due to outreachy-kernel delivery failure>
> 
> 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.

Thanks for the directon.  I am working on that first step.
alisons
> 

Re: IIO Coding Task 2 ?

[Alison Schofield]

.........................snip...................
> > >
>t > >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.
> 
> Thanks for the directon.  I am working on that first step.
> alisons
> > 
Hi Daniel,
I'm ready to send out the RFC PATCH, but I wasn't able to meet
one of your requests.  I did not find a place where the locking
was not done. The 'sample' is one where mlock was used with
iio_buffer_enabled. I think it illustrates the API well because
it clearly shows the before/after that would occur in other drivers.
Send it? 
Thanks,
alisons

Re: IIO Coding Task 2 ?

[Daniel Baluta]

On 01.03.2016 05:47, Alison Schofield wrote:
> .........................snip...................
>> t > >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.
>> Thanks for the directon.  I am working on that first step.
>> alisons
> Hi Daniel,
> I'm ready to send out the RFC PATCH, but I wasn't able to meet
> one of your requests.  I did not find a place where the locking
> was not done. The 'sample' is one where mlock was used with
> iio_buffer_enabled. I think it illustrates the API well because
> it clearly shows the before/after that would occur in other drivers.
> Send it?
> Thanks,
> alisons
>
Yes please :). Send the patches as RFC's, don't forget to Cc linux-iio 
mailing list.
Also, you can expand your searches to drivers/iio/.

thanks,
Daniel.