Rtems 4.6.99.3 - cdefs.h

[Ralf Corsepius]

On Wed, 2006-05-03 at 16:53 -0500, Joel Sherrill wrote:
> Steven Johnson wrote:
> 
> >Further to the following email,
> >
> >it turns out that the only header file installed by rtems that refers to
> >cdefs.h is rtems_bsdnet_internal.h
> >
> >It #include's both 'rtems/cdefs.h' and 'sys/cdefs.h'
> >
> >  
> >
> It has been a long time goal to slowly eliminate the various versions of 
> cdefs.h or
> at least turn them into a .h file used only at build time.
> 
> >Why?
> >
> >I cant see any definitions in rtems/cdefs.h that arent made in
> >sys/cdefs.h.  Shouldn't the #include to 'rtems/cdefs.h' be changed to
> >'sys/cdefs.h' and then the second (and lower) #include of 'sys/cdefs.h'
> >be removed?
> >
> >If this is done, i don't find any other references to 'rtems/cdefs.h',
> >so couldn't it be safely removed?

Nope. The problem is much more complicated than it looks.

1. cdefs.h is not covered by any standard. It is a
de-facto/implementation-defined pseudo-standard header being defined by
the implementations to be found in various BSD-derivatives.

For RTEMS, we use the implementation from FreeBSD as reference and try
to minimize it.

2. Unfortunately newlib has chosen to provide a (BSD-incompatible)
cdefs.h of its own.

=> There exist 2 conflicting, largely incompatible implementations of
sys/cdefs.h

To resolve this issue there exist several different approaches:

1. Eliminate all cdefs.h in RTEMS source tree and rely on an external
libc providing sys/cdefs.h 

This approach is problematic twice:
- BSD compatibility
- sys/cdefs.h is not guaranteed to be provided by a libc.

Newlib's sys/cdefs.h isn't much of a problem, because we can patch it
for the amount of BSD compatibility required.

2. Eliminate sys/cdefs.h from newlib.
This is hardly possible, because
- RTEMS hardly is in a position to introduce such a drastic measure to
newlib.
- sys/cdefs.h is used by newlib when bootstrapping it.

3. Don't use sys/cdefs.h inside of the RTEMS source tree, but use a BSD
compatible sys/cdefs.h replacement as private header inside of the
source tree.

> I tried to remove the sys/cdefs.h and rtems/cdefs.h from the RTEMS tree and
> now know that the newlib sys/cdefs.h is NOT sufficient to build RTEMS.
> It is missing at least definitions of  _dead2. 
Exactly, BSD compatiblity hits.

> I have not had a chance to see if the sys/cdefs.h in RTEMS can be eliminated
> and keep rtems/cdefs.h.  Having an RTEMS sys/cdefs.h and a newlib 
> sys/cdefs.h
> is confusing.  At least keeping rtems/cdefs.h would make it obvious it 
> is ours.
Right, what you currently see inside of the source tree probably is left
overs from different and contradicting efforts to implement one of the
alternatives above.

Similar considerations apply other BSD headers (Definitely to
sys/queue.h, I think there are more, but I don't recall off-head).

> The long term goal is to eliminate RTEMS using cdefs.h as much as possible
> until it is an internal file supporting ported BSD code.
Right.

Ralf