On Mon, Jun 15, 2020 at 11:28 AM Sebastian Huber < sebastian.hu...@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.hu...@embedded-brains.de > >> <mailto:sebastian.hu...@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. > > 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. > +1
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel