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.
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
