On 15/06/2020 20:23, Joel Sherrill wrote:
On Mon, Jun 15, 2020 at 11:28 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto: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> >> <mailto: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.
I added a ticket for this: https://devel.rtems.org/ticket/4005 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
