On 2014-04-09 13:44, Joel Sherrill wrote:
I have a number of concerns about this.
The gap in the object type in the enum is very inconsistent with the other ids.
Does it negatively impact the object class tables?
No, since we still have:
/** This macro is used to generically specify the last API index. */
#define OBJECTS_RTEMS_CLASSES_LAST OBJECTS_RTEMS_BARRIERS
Does it negatively impact the RTEMS object services at the API level? Remember
there are rtems_object services which work universally on any id. I think you
are breaking the orthogonality of them.
What is the intended use case?
The use case is to set a scheduler for a task. See patch 4.
Where is documentation?
It is in Doxygen.
http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html
I assume this is part of having multiple schedulers but you are basically
tossing unjustified code over the wall without giving us a plan. I have no idea
why the code is desirable based on what you have said. And it breaks the
uniform use of IDs.
http://www.rtems.org/wiki/index.php/SMP#Clustered_Scheduling_2
http://www.rtems.org/pipermail/rtems-devel/2013-November/004950.html
We can also use something else to identify schedulers (e.g. a string), but
using an object identifier was the most natural in the RTEMS context from my
point of view.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
