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

[Joel Sherrill]

Thomas Doerfler wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Chris,
>
>Chris Johns schrieb:
>  
>
>>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 ?
>>    
>>
>
>This may be part of the discussion. And from Ralf complaint I have
>learnd that things related to the ATA driver do NOT belong there.
>  
>
>>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 ? :-)
>>    
>>
>
>I think this touches the art of software development: how can we keep
>confdefs.h (and friends) as easy to use as possible?
>
>  
>
>>I do not agree with this argument. This file originated as a way of
>>allowing examples, samples, and tests to be configured.
>>    
>>
>
>Hm. Good argument. Why did we need it? Let me think.
>
>- - It was a way to let the test/sample applications be portable between
>all the architectures/BSPs available for RTEMS.
>
>- - It makes it easier to write tests/examples and to maintain them
>between RTEMS revisions.
>  
>

That's where confdefs.h originated.  It proved to be more generally 
useful than
just tests and USERS!! starting using it.  We fixed and improved it 
since real
users were using it. 

>Another question: Why does it reside in "sapi/include"? If it's use
>werelimited to the tests/samples, it would be better to have it in the
>testsuites tree. And by the way, then I would not have violated the
>cpukit separation which lead to this discussion thread.
>
>  
>
Over time, RTEMS has defined standard APIs for standard drivers including
clock, console, NICs, and RTC.  These driver interfaces are defined in 
.h files
under cpukit so technically at this point in time, everything confdefs.h 
knows
about is defined -- but not necessarilyimplemented -- in cpukit.  
Because confdefs.h
is cross API and knows a bit about Classic, POSIX, and ITRON, it is in sapi.

 From my perspective, if we are now claiming RTEMS has a standard interface
for ATA device drivers, then it should be defined in CPUKIT.  
Implementations
can be libchip, libbsp, or application space.

>>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.
>>    
>>
>
>Ok. I also like the idea to not tinker around in the BSP for application
>specific things. But I don't see a difference between adding special
>code into the application to add new drivers and to set some
>configuration variables for confdefs.h (or a future conf_ata.h).
>
>  
>

A conf<SUBSYSTEM> might not be a bad solution.  confdefs.h is already large.

>>There is also plug and play type systems that need to probe hardware.
>>    
>>
>
>I am sure my approach will not meet all possible applications. For these
>applications, your coded method may be the better one, but I think this
>only covers below 10% of the RTEMS applications.
>  
>

confdefs.h were never intended to do EVERY application -- just most.  And it
does that fairly well.

>  
>
>>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.
>>    
>>
>
>Agreed, this was not the right place to do it.
>
>  
>
As long as RTEMS does not have a standard ATA driver interface.

>>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 do not want to force anybody to use the configuration, but I think it
>may be convenient for many users.
>
>Currently an RTEMS user has to use various configuration mechanisms to
>get a basic system up and running, and I think a more common approach
>would help here.
>
>  
>

Agreed.  I am not 100% sure I could generate a functional ATA/FAT aware 
application
on a pc386.

>wkr,
>Thomas.
>
>- --
>
>- --------------------------------------------
>Embedded Brains GmbH
>Thomas Doerfler        Obere Lagerstrasse 30
>D-82178 Puchheim       Germany
>email: Thomas.Doerfler at embedded-brains.de
>Phone: +49-89-18908079-2
>Fax:   +49-89-18908079-9
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFEt7mg59Jd6und9wsRArNyAJ99GSc+MPfxtRDQlm29tpYMA56JuwCfUoRc
>vOQUloyrB5A3+fLpESdgqVE=
>=R4k1
>-----END PGP SIGNATURE-----
>  
>