On 01/12/2020 07:49, Chris Johns wrote:
On 1/12/20 5:31 pm, Sebastian Huber wrote:
On 30/11/2020 21:43, Joel Sherrill wrote:
On Mon, Nov 30, 2020 at 1:06 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 30/11/2020 20:00, Joel Sherrill wrote:
> Applications can use something like:
>
> #if __RTEMS_MAJOR__ >= 5
>
> POSIX threads are always enabled ...
>
> #endif
>
> This is a change to our public API that was completely unnecessary.
>
> We do not require changes to application code when it can be
avoided.
If you enable the POSIX API, then you don't have to change
anything in
your application. You can use now more of the POSIX API without
having
to enable it explicitly. It is up to you if you want to rely on
this or not.
What about rtems-libbsd? It fails to build because of this flag having changed
meaning.
I think we broke a contract on what the meaning of a published
feature macro means.
Sorry, I still don't understand the problem. You always had to build libbsd with
a BSP which was configured with --enable-posix.
Since now more POSIX APIs are enabled by default, we may remove this check from
libbsd. However, this requires someone with enough time to implement and test
this.
The semantics of what is being offered by the option has changed. Yes adding the
option does make things build but it is now inconsistent in what it covers and
how it is being detected and used. Papering over this only delays the point in
time we need to address it
What is offered by default changed. What didn't change is the meaning of
RTEMS_POSIX_API define. What you want to do now is making use of the
additional POSIX features enabled by default in RTEMS 5 and later. This
is the problem we have to address. I suggested to use the
__RTEMS_MAJOR__ to figure out what is enabled by default.
Can the enable-posix option be removed and always enabled? We minimise the
executable size automatically. Always being enabled means the option in the
header is always true and any dependent package or build system can happily
continue and be updated when it suites.
I didn't remove the RTEMS_POSIX_API completely, since the signals have
an impact on the size of the Thread_Control and may pull in some extra
code which is probably very seldom used (e.g. the sporadic server
stuff). I tried hard to make sure that the additional POSIX features
enabled now by default don't add an overhead to applications which don't
use them. An increased Thread_Control size affects all applications.
Failing that can the default always be true?
Yes, this would be an option, but if we do this, then we make a change
which impacts existing application configurations.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hub...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
