Rtems 4.6.99.3 - cdefs.h

Thu May 4 13:26:51 UTC 2006

Hi,

So to summarize, the best approach wold be to:

1. Rename all references in rtems from sys/defs.h to rtems/cdefs.h
2. Remove sys/cdefs.h from the rtems source tree.

Is it proposed to not install "rtems/cdefs.h" in the install phase of
building rtems, because its only used internally?

The problem I have with not installing it, is there are installed
headers that would require rtems/cdefs.h, so i think installing it cant
be avoided, unless its features are not relied on by installed headers
at all.  Is this right?

1 & 2 are largely mechanical, I could probably put a patch together to
do this in about an hour, and it would certainly get rid of the double
declaration i am experiencing.  The question remains, should
"rtems/cdefs.h" be installed, and if not, how should headers that refer
to it, that are installed be dealt with.

Another (more work) option would be to remove all reference to
"sys/cdefs.h" and "rtems/cdefs.h" and just fix all the build errors that
introduces.  It seems cdefs.h largely deals with making certain
attributes on functions/variables work with non ansi-C compatible
compilers, and also with early versions of GCC.  Is this a concern of
4.6.99.3?  If it was specified that it required an ansi-C compatible
compiler, then a lot of the definitions would become redundant and could
possibly be removed.  Other support also seems to be for ancient
versions of GCC (< V2.5).  Are these versions supported with 4.6.99.3? 
Is any other compiler other than GCC really supported for building
RTEMS?  If the answer to these is no, then I think it may not be a
hugely complicated task just to remove cdefs.h altogether, and just
change the code to build properly using GCC > V4 (if thats what is the
requirement).

Apart from:

rtems-4.6.99.3/cpukit/libcsupport/include/sys/ioccom.h:#include
<sys/cdefs.h>

The rest of the declarations seem to come from the networking code:

rtems-4.6.99.3/cpukit/libnetworking/net/if.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/net/if.h: * FIXME - HACK: BSD
defines __BSD_VISIBLE in sys/cdefs.h
rtems-4.6.99.3/cpukit/libnetworking/net/if.h: * RTEMS sys/cdefs.h
doesn't, so we enforce it here.
rtems-4.6.99.3/cpukit/libnetworking/net/ethernet.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/net/if_dl.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet_internal.h:#include
<rtems/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet_internal.h:#include
<sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/netinet/ip.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/netinet/tcp.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/resolv.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/libc/res_stubs.c:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/mount.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/socket.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/sysctl.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/libkern.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/rtprio.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/syslog.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/poll.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/un.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/uio.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/sys/queue.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/nfs/krpc.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/machine/in_cksum.h:#include
<sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/arpa/inet.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/arpa/nameser.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/netdb.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpcsvc/yppasswd.x:%#include
<sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpcsvc/ypclnt.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/clnt_soc.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/clnt.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/pmap_prot.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/pmap_clnt.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/xdr.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/pmap_rmt.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/rpc_com.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/auth.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/auth_unix.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/svc.h:#include <sys/cdefs.h>
rtems-4.6.99.3/cpukit/librpc/include/rpc/svc_soc.h:#include <sys/cdefs.h>

Would changing those references to rtems/cdefs.h create a problem for
inserting newer versions of the BSD network stack into rtems.  Or isnt
this a consideration?

Im happy to do the work needed to resolve this, because these 2 references:
rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet_internal.h:#include
<rtems/cdefs.h>
rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet_internal.h:#include
<sys/cdefs.h>

Causes me problems, due to things being declared twice.  If nothing
else, 1 of these #include's needs to be removed.  If that all that is
done, which one should it be? <sys/cdefs.h> ?

Steven

Ralf Corsepius wrote:

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