All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Jonathan Cameron <jic23@kernel.org>,
	Julio Cruz <jcsistemas2001@gmail.com>,
	Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Peter Meerwald <pmeerw@pmeerw.net>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Daniel Baluta <daniel.baluta@intel.com>,
	Paul Cercueil <pcercuei@gmail.com>
Subject: Re: read /dev/iio:device0 return -1 (Invalid argument)
Date: Mon, 4 Jan 2016 13:46:48 +0100	[thread overview]
Message-ID: <568A69B8.9080406@metafoo.de> (raw)
In-Reply-To: <568A58C3.6060804@kernel.org>

On 01/04/2016 12:34 PM, Jonathan Cameron wrote:
> On 04/01/16 04:59, Julio Cruz wrote:
>> Hi Jonathan,
>>
>> Previously, you help me about an issue related with data loss. You suggest
>> me to debug deep in the core elements. I will try to summarize the results
>> below for future reference.
>>
>> When there is not data available in the buffer (kfifo), and the application
>> try to read data (using "read" function), it return zero (0).
>>
>> If libiio will be used to read the data, there is a problem (detailed at
>> https://github.com/analogdevicesinc/libiio/issues/23). In brief, Paul
>> (pcercuei) suggest me that this issue must be manage by the driver, in this
>> case, return -EAGAIN when there is not data available [Resource temporarily
>> unavailable (POSIX.1)].
>>
>> After review the core elements as suggested, I changed the line (in
>> function iio_read_first_n_kfifo of kfifo_buf.c) as below:
>>
>> - return copied;
>> + return copied == 0 ? -EAGAIN: copied;
>>
>> Do you think will be OK like this?
> Hmm.. This is an interesting one (thanks for tracking it down)
> 
> The man page for read indeed allows for this to occur.
> 
>        When attempting to read a file (other than a pipe or  FIFO)  that  sup‐
>        ports non-blocking reads and has no data currently available:
> 
>         *  If  O_NONBLOCK  is  set,  read()  shall  return −1 and set errno to
>            [EAGAIN].
> 
> 
> However the issue here is that this is an ABI change and there may
> unfortunately be code out there relying on it returning 0.

We never propagate 0 to userspace though. The referenced function is
iio_read_first_n_kfifo() which is an internal function. The function that
handles the userspace ABI is iio_buffer_read_first_n_outer() and here, as
Daniel pointed out, there are two things that can happen.

We are in non-blocking mode and iio_read_first_n_kfifo() returns 0. In that
case we'll return -EAGAIN as mandated by the specification.

We are in blocking mode and iio_read_first_n_kfifo() returns 0. In that case
we'll go back to waiting for more data and we'll only return if either data
was received or the application was interrupted by a signal. In the former
case we'll return the number of received bytes in the later case -ERESTARTSYS.

So either way we should never return 0, something else must be going on.


Btw. letting iio_read_first_n_kfifo() return -EAGAIN will break blocking mode.

- Lars

  parent reply	other threads:[~2016-01-04 12:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12  8:36 read /dev/iio:device0 return -1 (Invalid argument) Julio Cruz
2015-12-12 11:51 ` Jonathan Cameron
     [not found]   ` <CAAn_ec_=9syP4j+g5GRMCB-+7vCWE1XqryE6KWUm=auUBZE=uQ@mail.gmail.com>
2015-12-12 12:35     ` Jonathan Cameron
2015-12-12 12:41       ` Julio Cruz
2015-12-13 10:44         ` Julio Cruz
2015-12-13 12:14           ` Jonathan Cameron
2015-12-13 14:42             ` Julio Cruz
2015-12-13 15:21               ` Jonathan Cameron
2016-01-04  4:59                 ` Julio Cruz
2016-01-04 11:34                   ` Jonathan Cameron
2016-01-04 12:29                     ` Daniel Baluta
2016-01-04 12:46                     ` Lars-Peter Clausen [this message]
2016-01-04 18:22                       ` Jonathan Cameron
2016-01-05 11:57                         ` Julio Cruz
2016-01-06 18:27                           ` Jonathan Cameron
2016-01-06 18:59                             ` Jonathan Cameron

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=568A69B8.9080406@metafoo.de \
    --to=lars@metafoo.de \
    --cc=daniel.baluta@intel.com \
    --cc=jcsistemas2001@gmail.com \
    --cc=jic23@jic23.retrosnub.co.uk \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pcercuei@gmail.com \
    --cc=pmeerw@pmeerw.net \
    /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.