Re: RTEMS SMP Status Report v3
On 23/12/16 02:01, Chris Johns wrote: On 22/12/2016 21:43, Sebastian Huber wrote: - Chris Johns 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 and 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
Newlib and GCC Update for RTEMS 4.12
Hello, I updated the RSB to use Newlib 2.5.0 with this patch https://sourceware.org/ml/newlib/2016/msg01190.html and GCC 6.3.0 (or1k GCC 4.9.3, epiphany GCC 4.9.2). All users of the RTEMS master should update their tool chains. This tool set is a hot candidate for the RTEMS 4.12 release. -- 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
Re: libbsd update to FreeBSD head (2016-08-23)
On 09/11/16 09:38, Sebastian Huber wrote: Hello, I update currently the libbsd to FreeBSD head (2016-08-23) from FreeBSD 9.3. This is a very big jump in terms of FreeBSD development. The main goal is to catch up with FreeBSD and unify the baseline of the different parts of the libbsd. The network, USB and SD/MMC card parts used different FreeBSD versions. Thus, using an USB network component didn't work before due to incompatible network stack interfaces. There will be some work to do for each supported BSP after the update, e.g. adjustment of network interface drivers. I cannot do this for everything. I will create a "4.12-freebsd-9.3" branch before the update in the next days and then commit the update to the master. The tool chain is now ready for the update. I will commit the update to FreeBSD head (2016-12-10, Git mirror commit 80c55f08a05ab3b26a73b226ccb56adc3122a55c) probably in mid January. -- 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
Re: Newlib and GCC Update for RTEMS 4.12
Thanks Sebastian. I have some patches to RTEMS coming which require the new newlib. I don't plan to add autoconf logic to disable it when the old tools are in use. I am also nibbling at removing some of the similar logic added during the SMP work. --joel On Dec 23, 2016 7:54 AM, "Sebastian Huber" < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > I updated the RSB to use Newlib 2.5.0 with this patch > > https://sourceware.org/ml/newlib/2016/msg01190.html > > and GCC 6.3.0 (or1k GCC 4.9.3, epiphany GCC 4.9.2). All users of the RTEMS > master should update their tool chains. This tool set is a hot candidate > for the RTEMS 4.12 release. > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS SMP Status Report v3
On Fri, Dec 23, 2016 at 4:45 AM, Sebastian Huber wrote: > On 23/12/16 02:01, Chris Johns wrote: >> >> On 22/12/2016 21:43, Sebastian Huber wrote: >>> >>> - Chris Johns 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 and > 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
