rtems waf, examples, and RTEMS_POSIX_API

[Chris Johns]

On 2/12/20 3:39 am, Gedare Bloom wrote:
> 
> 
> On Tue, Dec 1, 2020 at 12:33 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> 
>     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>
>     >>> <mailto: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.
> 
> 
> IMO: the meaning of RTEMS_POSIX_API remains consistent. It means RTEMS was
> ./configure'd with --enable-posix if true, otherwise it is false.
> 
> What that _implies_ to the application does change, but I am opposed to taking
> any action to modify the behavior we have. The concerns noted by Joel and the
> advice by Sebastian should be codified in documentation to clarify the situation
> for users who care about what POSIX features are always available vs conditioned
> on RTEMS_POSIX_API, and how the set of default features may change over time.
> What really matters is whether we want to ensure forward compatibility for the
> existing defaults. I think that makes sense.

To me 'RTEMS_POSIX_API = False' does not do what it says. The POSIX API is still
present except for signals and they should only be used when porting code. A new
option in the new build system called 'RTEMS_POSIX_SIGNALS' would be better long
term.

> As I understand the historical introduction of the option was to keep the code
> size small, and there are still POSIX features that can pull in excess code that
> may be hard to 'prune' (by LTO), then it makes sense to keep the feature option.

My understanding of the original question was in relation to libbsd. Currently
to build libbsd you need 'RTEMS_POSIX_API = True' which translates to enable
POSIX signals and I think this is ironic because libbsd does not support
signals! :) This appears confusing to me.

Chris

>     > 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.

Thanks. I was wondering about the reason. Why not make it clear by adding
RTEMS_POSIX_SIGNALS? This would minimise the churn.

>     >
>     > 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.

I still feel removing RTEMS_POSIX_API and making it always true is the best path.

Chris