rtems waf, examples, and RTEMS_POSIX_API

Tue Dec 1 16:39:09 UTC 2020

On Tue, Dec 1, 2020 at 12:33 AM Sebastian Huber <
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>> 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.

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.

> >
> > 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/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201201/a2a4b87c/attachment.html>