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?
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
