rtems waf, examples, and RTEMS_POSIX_API

[Sebastian Huber]

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.huber at embedded-brains.de
>>> <mailto:sebastian.huber at 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.hubere at 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/