[PATCH 02/12] score: Add ticks per second to configuration

[Chris Johns]

On 8/04/2016 7:34 PM, Sebastian Huber wrote:
> On 08/04/16 11:22, Chris Johns wrote:
>>> I don't think its feasible to avoid <rtems/confdefs.h>. Its now the only
>>> way to create a configuration.
>>>
>>
>> Sorry, but I do not like confdefs getting these values in this way.
>> This is not a great long term solution. Easy to add very hard to remove.
>>
>> Maybe you need make some score level variables and compute the values
>> during configuration.
>
> In this case they are no longer read-only.

Yes and holding RAM base computed values does use a couple of ints. Is 
there another reason they need to be read only?

This change exposes implementation details unrelated to the 
configuration table. I cannot see a way we can avoid this with out 
having internal intermediate values. What is being proposed is an 
optimization and one worth doing but it exposes an optimization detail 
in an unfortunate way. If the implementation changes and these values 
are no longer needed can we remove them? We have no control on who uses 
them once we add them.

>
> One way to test it would be to use
>
> #define CONFIGURE_MICROSECONDS_PER_TICK 1000000000
>
> and exploit the limited integer ranges. Doesn't work if we check this
> configuration error in <rtems/confdefs.h>.
>

A concern for me is the separation of the definition and the management. 
As a compromise maybe documenting the fields as generated would help and 
then provide a macro in the configuration table header to set the user 
visible value which then sets the generated values.

I would prefer not to pollute the table.

Chris