On 15/06/2020 18:28, Sebastian Huber 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?
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.
How should I name this property of an object? Is it the scope of the
object (see
https://man7.org/linux/man-pages/man3/pthread_attr_setscope.3.html) or
the visibility of the object?
Is "node in a multiprocessing network" a good phrase? I would like to
make it a bit easier to separate if from SMP.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
