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

[Chris Johns]

Thomas Doerfler wrote:
> 
> 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.

I suppose this leads to what goes in confdefs.h and what does not ?

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

As a collection point for the RTEMS kernel settings I have no problem 
and for the basic setup of drivers used to run samples, examples and 
tests then it is ok. Meeting the needs of the "average user" is 
something I have a problem with. I am yet to meet the average RTEMS 
user. Most tend *not* to be average users. :-)

As a means of getting into RTEMS it is fine to have something in 
confdefs.h, but I suspect the average user soon needs to start adding 
extra features or setups into BSPs and/or applications. At what point 
does confdefs.h become too complex and we need confofconfdefs.h ? :-)

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

I do not agree with this argument. This file originated as a way of 
allowing examples, samples, and tests to be configured.

Consider a BSP supplied with a board. A user may not wish to change the 
BSP so they can upgrade the BSP as the suppler fixes problems. A user 
adding their specific drivers for plug in hardware can do this in the 
application without consideration of confdefs.h.

There is also plug and play type systems that need to probe hardware.

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

Yeap I agree.

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

Helping a user is great and encouraged, but we should honor the rules of 
the cpukit which is what Ralf objected t0o. I agree with him.

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

I see this as something we should not try to define or solve directly in 
RTEMS. It is the domain of the user and their specific software 
architecture and us discussing it would do little more than agree that 
every system using RTEMS (or RTOS) has to find a suitable balance. I 
think this agrees with what you have said.

I have developed systems with all drivers in the application, a mix with 
some in the application and some in the BSP, and finally all drivers in 
the BSP. Each system had different requirements.

I like to view the BSP from the point of view of a hardware developer 
supporting a target. They provide a BSP which supports the interfaces on 
the target that RTEMS can support. If the target provides a bus and a 
user plugs a card in they can either customise the BSP or implement the 
drivers in the application.

Regards
Chris