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