Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

On 15/06/2020 20:23, Joel Sherrill wrote:

>
>
> On Mon, Jun 15, 2020 at 11:28 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 15/06/2020 18:24, Sebastian Huber wrote:
>
>     > On 15/06/2020 18:13, Joel Sherrill wrote:
>     >
>     >> On Mon, Jun 15, 2020 at 10:52 AM 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:
>     >>
>     >>     Hello,
>     >>
>     >>     should the use of RTEMS_GLOBAL be an error in
>     >>     rtems_semaphore_create(),
>     >>     rtems_task_create(), rtems_message_queue_create(), and
>     >>     rtems_partition_create() if RTEMS was configured without
>     >>     multiprocessing
>     >>     enabled?
>     >>
>     >>
>     >> Based on the original use cases, I would say no. The idea was that
>     >> you could create
>     >> objects and attach to them to limit cohesion. The intention was to
>     >> avoid the use of
>     >> global variables for sharing object Ids.  If I offer a service
>     via a
>     >> message queue
>     >> globally and my library/service is deployed in a non-MP
>     >> configuration, it should still
>     >> work. For tasks, that would imply events. For partitions, it just
>     >> means the memory is
>     >> available to "the system" which is a single processor.
>     >
>     > Ok, but I think this is a bit inconsistent to the
>     >
>     > #if defined(RTEMS_MULTIPROCESSING)
>     >   if (
>     >     _Attributes_Is_global( attribute_set )
>     >       && !_System_state_Is_multiprocessing
>     >   ) {
>     >     return RTEMS_MP_NOT_CONFIGURED;
>     >   }
>     > #endif
>     >
>     > error case. If your system has only one node and is configured for
>     > multiprocessing shouldn't this behave exactly as an uniprocessor
>     > system with multiprocessing disabled?
>
>
> Agreed. With 30 years of hindsight, we should ensure that affinity and
> this setting follow the same behavior rule.

I added a ticket for this:

https://devel.rtems.org/ticket/4005