POSIX and return codes...

[Jakob Viketoft]

Hello Sebastian,

From: Sebastian Huber [sebastian.huber at embedded-brains.de]
Sent: Wednesday, February 28, 2018 11:55

> ----- Am 27. Feb 2018 um 13:11 schrieb Jakob Viketoft jakob.viketoft at aacmicrotec.com:
>
>> 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? :)
>
> I think you try to improve the wrong driver framework. This classic device support is a legacy API. It is inflexible
> and has a considerable overhead due to an excessive layering and the use of minor numbers. A driver registered
> via IMFS_make_generic_node() already provides the functionality you are asking.

I agree with the excessive layering, but it's not straightforward how IMFS_make_generic_node() works. Looking at e.g. https://git.rtems.org/rtems/tree/testsuites/libtests/newlib01/init.c, it seems like driver *user* is calling IMFS_make_generic_node() which seems a bit absurd (correct me if I'm wrong). You also noted that the API isn't stable yet which make me hesitate about switching over to this.

Practically speaking, I think need we have to have an immediate interim solution, along the lines Joel suggested, and then long term we could switch over to the IMFS_make_generic_node() way of doing things. However, I would need some more documentation on IMFS_make_generic_node() besides looking at examples in testsuites code.

The current POSIX API is what's exposed to our users and changing that in any way is not done at the flip of a coin.

We don't have any other filesystems in RTEMS (apart from /dev/*) if that has any impact either way.

       /Jakob