RTEMS SMP Status Report v3

[Gedare Bloom]

On Fri, Dec 23, 2016 at 4:45 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 23/12/16 02:01, Chris Johns wrote:
>>
>> On 22/12/2016 21:43, Sebastian Huber wrote:
>>>
>>> ----- Chris Johns <chrisj at rtems.org> schrieb:
>>>>
>>>> On 22/12/2016 01:19, Sebastian Huber wrote:
>>>>>
>>>>> The POSIX API provides no binary semaphores, so task/interrupt
>>>>> synchronization is a problem. So, for drivers there is still a need for
>>>>> some RTEMS-specific APIs.
>>>>
>>>>
>>>> I like the idea of NP additions help us here. We already have
>>>> pthread_getaffinity_np.
>>>
>>>
>>> I don't like the idea of adding RTEMS-specific pthread_*_np() functions.
>>
>>
>> I do not really understand the reasons why. It seems you are ok with
>> "standard" non-standard calls but not "non-standard" non-standard or "RTEMS"
>> non-standard calls. I see any NP call as non-standard no matter the
>> acceptance or availability and I also think it is a good to borrow NP calls
>> where they exist rather than invent them however it does not give them an
>> elevated standing.
>
>
> If glibc/Linux adds a feature its a de-facto standard.
>
+1

>>
>>> The pthread_getaffinity_np(), etc. was invented by glibc (probably?).
>>
>>
>> I do not know.
>>
>>> I don't think RTEMS should be the trendsetter in this area.
>>
>>
>> Why not lead in this area?
>>
We don't have large enough user base or impact to lead by ourselves.
There is a good probability that we could introduce conflicting APIs
to other projects like Linux. I wouldn't strive for API compatibility
with Linux, but I also would avoid API incompatibility. What we could
do is push for certain non-portable APIs to be adopted in other
projects in parallel to RTEMS.

>>> It confuses users to have NP functions that are RTEMS-specific and NP
>>> functions that are available on Linux/BSD.
>>
>>
>> I am not sure why you think this is an issue. There are NP calls on
>> FreeBSD we do not support so using NP for portable code requires extra
>> effort from users. I think it would be a mistake to let users think
>> otherwise. Any code that uses RTEMS NP calls may not build on Linux or
>> FreeBSD and this is the same as using the Classic API so the gain is
>> neutral.
>
>
> Up to now every pthread NP function available in RTEMS is available on
> glibc.
>
This is a (mathematical) set problem. The way I see it, it is good for
our user-base if RTEMS NP functions are a subset of glibc/Linux. It is
bad from a forward-compatibility problem to introduce NP functions
that later get introduced in other projects with different parameters
or functionality. That's the risk of being a trendsetter.

>>
>> I like the idea of ELF notes being used to tag every API function in RTEMS
>> with the standard and API they come from. We can then have a tool to audit
>> the executable. There was a post recently from Nick Clifton on binutils
>> about annotating ELF binaries this way. Linux also has code to add notes to
>> ELF files.
>>
Is this described somewhere as an open project? What is the scope of it?

> Maybe add a PTHREAD_MUTEX_SIMPLE_NP mutex type.
>
This works in a relatively easy way to change.

> I still prefer a small special purpose API in <rtems/mutex.h> and
> <rtems/semaphore.h> for everything required by general purpose libraries and
> device drivers, e.g. priority inheritance mutexes, binary and counting
> semaphores.
>