| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
In uniprocessor configurations, use compile-time constants for
rtems_scheduler_get_processor_maximum() and
rtems_scheduler_get_processor(). This helps compilers and static
analyzers to deduce that some loop bodies are only executed once and
some conditional statements have a fixed outcome (may improve code
generation and reduce false positives).
In SMP configurations, directly provide the internal implementation for
performance reasons.
|
| |
|
|
|
|
|
| |
Rename _SMP_Get_processor_count() in _SMP_Get_processor_maximum() to be
in line with the API level rtems_scheduler_get_processor_maximum().
Update #3732.
|
| |
|
|
|
|
|
|
|
|
|
| |
Add rtems_scheduler_get_processor_maximum() as a replacement for
rtems_get_processor_count(). The rtems_get_processor_count() is a bit
orphaned. Adopt it by the Scheduler Manager. The count is also
misleading, since the processor set may have gaps and the actual count
of online processors may be less than the value returned by
rtems_get_processor_count().
Update #3732.
|
|
|
Rename rtems_smp_get_processor_count() in rtems_get_processor_count().
Make rtems_get_processor_count() a function in uni-processor
configurations to enable ABI compatibility with SMP configurations.
|
