Rtems 4.6.99.3 - cdefs.h

Thu May 4 21:31:57 UTC 2006

Steven Johnson wrote:

>Hi,
>
>So to summarize, the best approach wold be to:
>
>1. Rename all references in rtems from sys/defs.h to rtems/cdefs.h
>  
>
IMO only if they have to be changed from sys/cdefs.h to rtems/cdefs.h.
newlib has a sys/cdefs.h and it has most everything needed. 

Ideally we wouldn't use any cdefs.h but it is used

>2. Remove sys/cdefs.h from the rtems source tree.
>  
>

I am hoping this is easy. 

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

Unfortunately, this is the primary issue -- we don't want to install it 
but may have to

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

This is what is harder to know.  The question is not the compilers being 
supported,
it is the source of the code.  Are we making standard code from BSD more 
different
and thus harder to update.

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