Joel Sherrill joel at
Fri Oct 4 20:00:03 UTC 2019

On Fri, Oct 4, 2019 at 1:53 PM Peter Dufault <dufault at> wrote:

> > On Oct 4, 2019, at 14:04 , Joel Sherrill <joel at> wrote:
> >
> > Hi
> >
> > I am now looking at the second phase of processing <ctl>-C to generate
> > to have read() return -1/EINTR. I want to specifically add this support
> to termios
> > although I think other file types would have to address this
> independently,
> >
> > For termios, we need rtems_deviceio_read() to return -1/EINTR but it
> returns -1/errno
> > based on rtems_status_code from rtems_io_read(). The issue is that we
> don't have
> > anything that maps to EINTR in the rtems_status_code enumeration.
> >
> > Is there any objection to adding RTEMS_INTERRUPTED as a status code?
> >
> > I am open to suggestions for a better name.
> >
> Do you see a use for RTEMS_INTERRUPTED instead of to support EINTR defined
> behavior?  If you don't I'd name it RTEMS_EINTR so that it isn't overloaded.

I don't see if being used for any other purpose. I don't even expect it to
be returned from
a directive such that a user would have to process it. That makes

I don't see that there are many places that use Classic API status which
would allow interruption.

In general, on the POSIX operation side there may be more operations which
are interruptible
by the standard. We have interruptible blocking states but it all depends
on how the operation
is constructed if it isn't a threading/concurrency primitive.


> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list