Read-write configuration data

Claus, Ric claus at slac.stanford.edu
Fri Nov 9 20:33:39 UTC 2012


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.

> 
> 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?

	Ric

> 
> -- 
> 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.
> 
> 





More information about the devel mailing list