On Fri, Oct 4, 2019 at 1:53 PM Peter Dufault <dufa...@hda.com> wrote:
> > > > On Oct 4, 2019, at 14:04 , Joel Sherrill <j...@rtems.org> wrote: > > > > Hi > > > > I am now looking at the second phase of processing <ctl>-C to generate > SIGINTR is > > 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 RTEMS_EINTR a good candidate. 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. --joel > > 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. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
