POSIX and return codes...

[Joel Sherrill]

On Feb 26, 2018 8:27 AM, "Jakob Viketoft" <jakob.viketoft at aacmicrotec.com>
wrote:

Hello Joel,

From: Joel Sherrill [joel at rtems.org]
Sent: Monday, February 26, 2018 12:21

> On Feb 26, 2018 5:13 AM, "Jakob Viketoft" <jakob.viketoft at aacmicrotec.com>
wrote:
>> E.g. could it be possible for the translation mechanism to look if there
is already an errno defined and then return this instead of doing the error
code translation?

>> It seems like the translation I'm talking about happens in the
rtems_deviceio_write() function in cpukit/libcsupport/src/sup_fs_deviceio.c

> Completely random thought as I sit on a plane without code.

> Add a field to the arguments structure for errno. See it to zero before
the call. If it is set to non-zero after the call, then the driver wanted
to return errno directly. Otherwise translate.

This was my thought as well, I just wanted to bounce it off the RTEMS list
and also possibly get official support for a feature as this.


Now boarded on a different plane and have had another round of thinking.

What if an RTEMS status code were added like RTEMS_STATUS_IN_ERRNO and we
don't modify the arguments structure. Then a driver could return that
status to trip -1 and errno.

Just a thought. I think it would make the code cleaner but another core
developer should pipe up. I was up at 3am to catch a flight and could be
loopy. :)


> A middle step is to see if any of the unused RTEMS status codes make
sense to use and cover your use cases.

This is the way we do it today. Unfortunately, so many of the different
RTEMS codes are translated into the same errno codes which makes it very
hard to have an intelligent error reporting/differentiation.

      /Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180226/04a937f0/attachment-0002.html>