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

[Thomas Doerfler]

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

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.

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

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

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

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

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