On 01/02/17 15:22, Joel Sherrill wrote:


On Feb 1, 2017 8:02 AM, "Sebastian Huber" <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP     : Public key available on request.

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

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to