RTEMS SMP Status Report v3
sebastian.huber at embedded-brains.de
Fri Dec 23 09:45:49 UTC 2016
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
>>>> some RTEMS-specific APIs.
>>> I like the idea of NP additions help us here. We already have
>> 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.
>> 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
Up to now every pthread NP function available in RTEMS is available on
> 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:
>> 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. :)
Maybe add a PTHREAD_MUTEX_SIMPLE_NP mutex type.
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
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel