This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: [Fwd: I/O errors - confusion]
On Tue, 2003-03-18 at 10:58, Nick Garnett wrote:
> Gary Thomas <gary at mlbassoc dot com> writes:
>
> > I saw no response to this - can someone (Nick?) please comment?
> >
>
> Oops. I had it set aside to respond to, but then forgot it.
>
> >
> > I was looking into a problem (dealing with abnormal exits
> > from I/O functions) and I'm a bit confused.
> >
> > In particular, in io/fileio/current/src/devfs.cxx, there
> > is a test
> > if (-EAGAIN == err)
> > Looking at the underlying cyg_io_XX functions, I don't think
> > that they will ever return a negative value.
>
> Can't they get error codes from the drivers? In particular, I suspect
> that this code is intended to interact with this piece of code in
> serial.c:
>
> #ifdef CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING
> if (!cbuf->blocking) {
> *len = size; // characters actually read
> res = -EAGAIN;
> break;
> }
> #endif // CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING
>
>
> >
> > Also, that particular piece of code seems wrong to me. My
> > experience is that if I have a device in a non-blocking mode
> > and there is no data (to be read), the value of read() is
> > an error = EWOULDBLOCK. The code currently returns no error,
> > but also no data. A generic piece of "read this" code will
> > thus not be able to tell the difference between actually
> > reaching the end of data (like on a file) vs. not having
> > any data at the moment (which it may be prepared to handle
> > in some other fashion). I think this routine should behave
> > like this patch:
> >
> > Index: io/fileio/current/src/devfs.cxx
> > ===================================================================
> > RCS file: /misc/cvsfiles/ecos/packages/io/fileio/current/src/devfs.cxx,v
> > retrieving revision 1.5
> > diff -u -5 -p -r1.5 devfs.cxx
> > --- io/fileio/current/src/devfs.cxx 23 May 2002 23:06:07 -0000 1.5
> > +++ io/fileio/current/src/devfs.cxx 9 Mar 2003 15:52:41 -0000
> > @@ -352,12 +352,18 @@ static int dev_fo_read (struct CYG_
> > iov->iov_base,
> > &len);
> >
> > if( -EAGAIN == err ) // must be in non-blocking mode
> > {
> > - uio->uio_resid -= len;
> > - return ENOERR;
> > + if (len != iov->iov_len) {
> > + // Something was read
> > + uio->uio_resid -= len;
> > + return ENOERR;
> > + } else {
> > + // No data, and non-blocking - tell user
> > + return EWOULDBLOCK;
> > + }
> > }
> > if( err < 0 ) break;
> >
> > uio->uio_resid -= len;
> > }
> >
> > although, I'm still confused about the -EAGAIN test.
> >
> > Comments?
> >
>
> I believe that should make things work a little better. However, I am
> now not sure that the serial.c functionality is correct. According the
> the POSIX standard:
>
> When attempting to read a file (other than a pipe or FIFO) that
> supports non-blocking reads and has no data currently available:
>
> · If O_NONBLOCK is set, read( ) shall return -1 and set errno to [EAGAIN].
>
> · If O_NONBLOCK is clear, read( ) shall block the calling thread until
> some data becomes available.
>
> · The use of the O_NONBLOCK flag has no effect if there is some data
> available.
>
> Returning some data *and* -EAGAIN doesn't make sense, it should return
> either one or the other. Your change fixes it up to work properly, but
> if serial.c was doing the right thing, that entire -EAGAIN test could
> be eliminated.
I agree - either there is data or not and the return code should
be very clear: EAGAIN means there is none, anything else means
there was. I think that the code in serial.c you quote should
return no error when there is data.
I am still not sure that we are using the errors in the proper
"state" (sometimes they are positive, sometimes negative).
Actually, finding this was a side effect of my problems with
VMIN (on a device which does not have O_NONBLOCK set). I'd
really appreciate some discussion on that as well.
--
------------------------------------------------------------
Gary Thomas |
MLB Associates | Consulting for the
+1 (970) 229-1963 | Embedded world
http://www.mlbassoc.com/ |
email: <gary at mlbassoc dot com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------