RTEMS SMP Status Report v3
gedare at rtems.org
Fri Dec 23 20:56:00 UTC 2016
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
>>> 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?
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
> Up to now every pthread NP function available in RTEMS is available on
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
More information about the devel