Usage of confdefs.h, was: Re: RTEMS-CVS is broken

Thomas Doerfler Thomas.Doerfler at imd-systems.de
Fri Jul 14 06:14:01 UTC 2006


Chris,

you are right, surely the drivers can be initialized under program
control. And the things I have added to confdefs.h are not required there.

On the other hand, you can start RTEMS completely without confdefs.h,
the only thing done there is to tinker together some configuration
tables, and it is also possible to create/provide these tables as data
structures defined in your application code.

The key point is, that using confdefs.h is much more convenient for the
average user, it reduces the basic system configuration (including the
"standard" device drivers) to a set of choices (like
APPLICATION_NEEDS_CONSOLE_DRIVER) and performs the appropriate internal
config steps for them.

And if you accept the usage of confdefs.h, it is inconsistent if parts
of your drivers are initialized automatically (in the device driver
table in RTEMS) and another part is not.

One flaw in libblock aswell as in the current ATA driver is, that their
embedded tasks have a hardcoded priority and so may (and do!) interfere
with the real time performance of an application. My cure for this is to
take set their priority in two new variables (ata_driver_task_priority
and swapout_task_priority) which must be provided by the application.

These variables are now created in confdefs.h with the following lines:

#ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
  /*
   * configure the priority of the ATA driver task
   */
#  ifndef CONFIGURE_ATA_DRIVER_TASK_PRIORITY
#    define CONFIGURE_ATA_DRIVER_TASK_PRIORITY \
            ATA_DRIVER_TASK_DEFAULT_PRIORITY
#  endif
#  ifdef CONFIGURE_INIT
  rtems_task_priority ata_driver_task_priority
    = CONFIGURE_ATA_DRIVER_TASK_PRIORITY;
#  endif /* CONFIGURE_INIT */
#endif

The average user simply must set the macro
"CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER" and confdefs.h will create the
configuration variable with a suitable default value.

I think another benefit of confdefs.h (or a similar, extended
configuration mechanism) is, that configuring a system is also a bit
more independent from the acutal Architecture/BSP used.

Note: I think the question, which drivers to use and how to configure
them is not a matter of the init code inside the BSP, but depends on the
application. Using the same board and BSP requires network and harddisc
access in some applications and in other cases this might not be
required. So the choice should be done in the application domain, not
the BSP domain.

wkr,
Thomas.

Chris Johns schrieb:
> Joel Sherrill wrote:
> 
>>
>> At first thought, this seems reasonable.    confdefs.h can stick to
>> the basics in CPU Kit.
>>
> 
> Why do we need to use confdefs.h ?
> 
> I have used the following type of BSP specific code in the past without
> the need to adjust the static driver table. The code uses
> 'rtems_io_register_driver'. I am yet to see the need for the change in
> confdefs.h.
> 
> Regards
> Chris
> 

wkr,
Thomas.


-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9



More information about the users mailing list