Use of RTEMS_GLOBAL in non-multiprocessing configurations?

[Sebastian Huber]

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

The background for this question is that I go though the entire Classic 
API and write specification items for it. The specification items 
include the API documentation:

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

I will probably add some text similar to the one in your e-mail to 
explain that the use of RTEMS_GLOBAL is all right in non-multiprocessing 
configurations.