On Fri, Dec 23, 2016 at 4:45 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > 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. > +1
>> >>> 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 >> neutral. > > > Up to now every pthread NP function available in RTEMS is available on > glibc. > 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 > semaphores. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
