Usage of confdefs.h, was: Re: RTEMS-CVS is broken
Thomas.Doerfler at imd-systems.de
Fri Jul 14 15:34:56 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
Embedded Brains GmbH
Thomas Doerfler Obere Lagerstrasse 30
D-82178 Puchheim Germany
email: Thomas.Doerfler at embedded-brains.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the users