Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

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