Read-write configuration data

[Sebastian Huber]

On 11/09/2012 04:00 AM, Mick Davis wrote:
> How do you mean read-only?
>
> That seems to be too broad a question to answer definitively.

Currently we have:

config_type config = { VAL1, VAL2, ..., VALN };

With read-only I mean:

const config_type config = { VAL1, VAL2, ..., VALN };

The configuration is initialized statically (e.g. via confdefs.h) and can 
reside in read-only memory (e.g. flash or MMU protected RAM).

>
> It would seem fine for the simple self-contained RTEMS + single app case.
>
> But where RTEMS fits for us is with flexible devices, where there's a lot of
> runtime configuration during RTEMS start up, and loadable modules.

Most of these values will be only evaluated in 
rtems_initialize_data_structures().  The only BSP specific routines that are 
used before this point are the low-level startup, bsp_start(), and 
bsp_work_area_initialize().  If they alter the configuration, then this is a 
hack and we should find an alternative.

>
> Hopefully RTEMS will get an elf loader in the future and this will be true more
> generally.
>
> So for instance, I specifically setup rtems_telnetd_maximum_ptys from a
> configuration at runtime, depending on what else is configured.

Ok, this value is evaluated during driver initialization.  So it should remain 
read-write.

>
> In the most recent apps I've been using the unlimited system for the number of
> tasks + queues etc.  But I can easily imagine going back to a system of setting
> up the Configuration_RTEMS_API before RTEMS starts with the number of resources
> based on an installed config.

Here a read-only configuration does no harm.

>
> Device_drivers seems like something that would often get setup depending on
> available hardware.

How does this work?  Can you give me a code example?  This could be a problem 
now since Configuration is already read-only.

http://git.rtems.org/rtems/commit/?id=ae4f125e86f8e824d0cbb0237c1c6762d70460d8

>
> The location and size of the heap is setup by the bootloader for us, after all
> images have been put into memory.

The work area initialization changed recently.  Please have a look at:

http://rtems.org/onlinedocs/doc-current/share/rtems/html/bsp_howto/bsp_howto_40.html#Initialization-Code-boot_005fcard_0028_0029-_002d-Boot-the-Card

>
>
> On the other hand, I have sometimes wondered if fixing the tick length would
> help performance.

The tick length is actually fix.

>
>
> I guess I don't know exactly what you plan.  And it might be OK if they're just
> read only after RTEMS is up and running, perhaps using the MMU.  But yes, in
> general, I would probably have an objection.
>
>
>
> On 08/11/12 23:48, Sebastian Huber wrote:
>> Hello,
>>
>> a lot of the RTEMS configuration is read-write data.
>>
>> Configuration_POSIX_API
>> Configuration_RTEMS_API
>> Device_drivers
>> _POSIX_Threads_Initialize_user_threads_p
>> rtems_fs_init_helper
>> rtems_libio_init_helper
>> rtems_libio_number_iops
>> rtems_libio_supp_helper
>> rtems_malloc_dirty_helper
>> RTEMS_Malloc_Heap
>> rtems_malloc_statistics_helpers
>> rtems_maximum_priority
>> rtems_minimum_stack_size
>> _RTEMS_tasks_Initialize_user_tasks_p
>> rtems_telnetd_maximum_ptys
>> _Scheduler
>>
>> Are there objections to make them read-only?
>>
>


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