On 23/12/16 02:01, Chris Johns wrote:
On 22/12/2016 21:43, Sebastian Huber wrote:
----- Chris Johns <chr...@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.
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.
Up to now every pthread NP function available in RTEMS is available on
glibc.
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.
Yes, definitely.
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
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
counting semaphores.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
