POSIX and return codes...

Jakob Viketoft jakob.viketoft at aacmicrotec.com
Tue Feb 27 12:11:03 UTC 2018

From: Joel Sherrill [joel at rtems.org]
Sent: Monday, February 26, 2018 14:36
>> 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.

Yes, that would work just as well for us and is even less work / impact.

> 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. :)

Anyone else? :)
Btw, how is it with practicalities, should we suggest a patch to implement it, is this someone specifics territory, do we need to create some sort of ticket to hang the patch on etc? Would love to get this implemented very soon since our current error reporting is a bit unsatisfactory.

>> 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.


More information about the devel mailing list