[PATCH 1/4] score: Add scheduler name

[Gedare Bloom]

On Wed, Apr 9, 2014 at 11:03 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-04-09 16:51, Gedare Bloom wrote:
>>>
>>> + at item DEFAULT VALUE:
>>> >+The default name is
>>> >+ at itemize @bullet
>>> >+ at item @code{" CBS"} for the CBS scheduler,
>>> >+ at item @code{" EDF"} for the EDF scheduler,
>>> >+ at item @code{"PRIO"} for the Deterministic Priority scheduler,
>>> >+ at item @code{"PAFF"} for the Priority Affinity scheduler, and
>>> >+ at item @code{"PSIM"} for the Simple Priority scheduler.
>>
>> PSIM with SMP, SIMP for the non-SMP.
>>
>
You have this in your patch:
#if defined(CONFIGURE_SCHEDULER_SIMPLE)
+  #if !defined(CONFIGURE_SCHEDULER_NAME)
+    #define CONFIGURE_SCHEDULER_NAME rtems_build_name('S', 'I', 'M', 'P')
+  #endif
+
   #define CONFIGURE_SCHEDULER_CONTEXT RTEMS_SCHEDULER_CONTEXT_SIMPLE(dflt)

-  #define CONFIGURE_SCHEDULER_CONTROL RTEMS_SCHEDULER_CONTROL_SIMPLE(dflt)
+  #define CONFIGURE_SCHEDULER_CONTROL \
+    RTEMS_SCHEDULER_CONTROL_SIMPLE(dflt, CONFIGURE_SCHEDULER_NAME)
 #endif

 /*
  * If the Simple SMP Priority Scheduler is selected, then configure for it.
  */
 #if defined(CONFIGURE_SCHEDULER_SIMPLE_SMP)
+  #if !defined(CONFIGURE_SCHEDULER_NAME)
+    #define CONFIGURE_SCHEDULER_NAME rtems_build_name('P', 'S', 'I', 'M')
+  #endif
+
So the SIMP is used but not documented.

> I didn't distinguish the non-SMP/SMP variants so far in the names.  One
> scheme could be
>
> "UCBS"
> "UEDF"
> "USIM"
> "UPRI"
>
> "MSIM"
> "MPRI"
> "MPRA"
>
It might make more sense to come up with useful acronyms for each
scheduler, e.g. DP for deterministic priority, SP for simple priority,
PA for priority affinity.

Will there ever be a need to distinguish more than one scheduler
instance like EDF0, EDF1, etc? I could see this may be the case for
the partitioned schedulers.

> with 'U' for uni-processor and 'M' for multi-processor.  What is your
> opinion on RTEMS object names vs. strings?  It could be also
>
> "Uni-Processor Constant Bandwidth Server"
> "worker pool"
> "IO"
>
I prefer the object id approach. I believe it is simpler and will be
less error-prone. The issue with it is the space contraints, which may
make the ids themselves hard to understand especially if we have to
encode things like U/M or numerical identifiers.

> --
> 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.