[PATCH] Rename CONFIGURE_SMP_MAXIMUM_PROCESSORS
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Feb 1 14:30:00 UTC 2017
On 01/02/17 15:22, Joel Sherrill wrote:
>
>
> On Feb 1, 2017 8:02 AM, "Sebastian Huber"
> <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
> On 01/02/17 14:53, Joel Sherrill wrote:
>
> The inclusion of SMP categorizes the option. Many, if not
> most, configure options have a second word which is the
> category. All the POSIX options include POSIX in the name,
> gnat, Go, etc.
>
>
> This is the only CONFIGURE_SMP_* option left, a category should
> consist of more than one member. The current pattern for the
> maximum defines is CONFIGURE_MAXIMUM[_CATEGORY]_*. A
> CONFIGURE_MAXIMUM_SMP_PROCESSORS is not really that great.
>
>
>
> All of our services are rtems_CATEGORY.
>
> It isn't about the shortest name with RTEMS. It is about the
> clearest name with grouping.
>
> I don't want to see this pattern violated and am opposed to
> this change.
>
> Otherwise, this would be CONF_MAX_CPUS or similar and we don't
> want that.
>
>
> In general I agree, however, SMP or non-SMP shouldn't be a
> category for the configuration. I think its like
> CONFIGURE_TICKS_PER_TIMESLICE or CONFIGURE_MICROSECONDS_PER_TICK a
> configuration option that sets up your application environment.
>
>
> Are there any options without SMP which should have them?
>
> If not, I agree.
I update currently the SMP chapter in the user manual. I thought that
this would simplify the things a bit.
The clustered scheduler configuration uses the SCHEDULER category. I
don't think we added anything SMP-specific except
CONFIGURE_SMP_MAXIMUM_PROCESSORS (to be renamed) and
CONFIGURE_SMP_APPLICATION (to be removed).
--
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.
More information about the devel
mailing list