On 2/12/20 3:39 am, Gedare Bloom wrote: > > > On Tue, Dec 1, 2020 at 12:33 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de> > >>> <mailto: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. > > > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
