[PATCH 2/4] rtems: Add scheduler identification

[Sebastian Huber]

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  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.