From: Daniel Baluta <daniel.baluta@intel.com>
To: Alison Schofield <amsfield22@gmail.com>
Cc: outreachy-kernel@googlegroups.com
Subject: Re: IIO Coding Task 2 ?
Date: Thu, 25 Feb 2016 10:55:56 +0200 [thread overview]
Message-ID: <56CEC19C.1010300@intel.com> (raw)
In-Reply-To: <56CEB5B4.5060605@intel.com>
[-- 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 --]
next prev parent reply other threads:[~2016-02-25 8:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 19:43 IIO Coding Task 2 ? Alison Schofield
[not found] ` <56CEB5B4.5060605@intel.com>
2016-02-25 8:55 ` Daniel Baluta [this message]
2016-02-25 18:26 ` Alison Schofield
2016-03-01 3:47 ` Alison Schofield
2016-03-01 9:43 ` Daniel Baluta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CEC19C.1010300@intel.com \
--to=daniel.baluta@intel.com \
--cc=amsfield22@gmail.com \
--cc=outreachy-kernel@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.