RTEMS SMP Status Report v3

[Chris Johns]

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.

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

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

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.

>
> QNX has a list of non-POSIX functions with POSIX-sounding names:
>
> http://www.qnx.com/developers/docs/am11/index.jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fposix_conformance_POSIX_sounding.html&cp=1_3_1_10_2
>
> The gray area is task/interrupt synchronization. I didn't find something useful on the QNX page.
>

Looks like they wedged themselves a little bit with some NP tagged calls 
and others not NP tagged. We should avoid this.

> What we definitely need is something like a binary semaphore (a one bit event).

Yes and a way to manage some extra threading parameters we have.

How do you propose we add such an API so it fits in with a POSIX API 
that has been changed to be self-contains and faster?

We have just dangled a carrot in front of our users so it would be great 
to find a workable path forward. :)

Chris