Read-write configuration data

[Sebastian Huber]

On 11/09/2012 09:33 PM, Claus, Ric wrote:
>
> On Nov 9, 2012, at 1:06 AM, Sebastian Huber wrote:
>
>> On 11/08/2012 10:59 PM, Claus, Ric wrote:
>>>>> If, however, you are intending to move toward compiled-in literals, then I am not in favor.  Ideally, all configuration constants would reside in some sort of database object, the contents of which could easily be recorded at run time.  This would be useful for gaining confidence in the ability to correctly reproduce past situations.
>>>>>
>>>>> What do you mean with "recorded at run time" and "reproduce past
>>>>> situations"?
>>> Some applications need to be able to record their configuration (including that of RTEMS) at run time so that at some later date when a test needs to be repeated, there is some hope of being able to reproduce it by reestablishing that configuration.  Relying on discipline to commit files, record tags, etc. invites mistakes.
>>>
>>> I'm not sure that this is any clearer than what I first wrote.
>>
>> How do you do this?
>
> Well, at the moment we don't.  It was expressed as a would-like-to-have in our group some time ago, so it's on my list but hasn't received much thought yet.  My read of Mick Davis' e-mail leads me to think that he's gone down this path, though.
>
>> Do you read the values of the configuration structures and
>> store them somehow?
>
>> Later you use the stored values and create a new
>> configuration from these values for a specific application?
>> What happens if
>> the configuration structure layout changes?
>
> Perhaps add a version number to protect against this?  Also, if it were an object with accessors we'd have a level of indirection behind which changes could be hidden.  The object itself maybe shouldn't be accessible from the global namespace, although that would cause backward incompatibility issues.

The configuration structures are usually generated via confdefs.h (are there 
users who do this differently?).  The pre-processor logic in confdefs.h is 
quite complex and necessary to derive the various configuration values, e.g. 
the workspace size estimate.  The workspace size estimate is influenced by a 
lot of RTEMS structures, e.g. Thread_Control which contains also 
Context_Control.  This makes it is very difficult to simply store the 
configuration value as is and use them later in a different version of RTEMS. 
On PowerPC a system with and without AltiVec support has different sizes of 
Context_Control and thus different workspace size estimates.

>
>>
>> I think we should record this requirement somewhere.  I was not aware that such
>> a use case exists.
>
> That brings up an interesting point.  Is there such a list of requirements and a development plan somewhere?

We have an open projects list:

http://wiki.rtems.org/wiki/index.php/Open_Projects

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
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.