Date: Sat, 1 Feb 1997 20:49:03 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, proff@iq.org Cc: hackers@freebsd.org Subject: Re: #include dependencies Message-ID: <199702010949.UAA17084@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Most of the headers are only used in the kernel. Kernel sources >I'm aware of this, this is why you see a number of #ifndef KERNEL. #ifndef KERNEL in kernel-only headers is nonsense (unless it is used to control a #warning or #error). >needs requiring different sys/types.h files. This appears not >to be the case and many kernel .c files rely on the fact that >sys/types.h is included in sys/libkern.h. sys/libkern.h includes <sys/types.h> because it is a modern self- sufficient header. Anything that depends on it exporting types is broken. Nothing much can depend on this since sys/libkern.h is only included directly libkern. Everything else in the kernel gets it by including sys/systm.h. sys/systm.h actually relies on sys/types.h being included in machine/cpufunc.h. >In terms of name-space pollution, the only difference between >polluting the name-space from the .C file compared to polluting it >from the included file, is that the name space *continues* to be >polluted even when the included file is changed to no longer be >dependent on the pollution. Do not be saying that this is a good No, the main difference is that applications have control over the amount of pollution. Some headers reserve a huge amount of namespace so they must not be included by other system headers. E.g., if the application includes <errno.h>, it must not define any identifiers start with `E' and followed by a digit or an upper case letter. If an application includes <termios.h>, it must not declare anything starting with `c_' or define anything starting with `B[0-9]', `I', `O', `TC' or `V'. >thing as it provides a continuity of name-space pollution in the >.C file. C code should only explicity resolve those include files >which *it* needs to define datatypes that it *directly* uses. >Anything else is inherently unstable across time and across changing >environments. By including standard headers in other headers, you make it hard for an application to include precisely the headers that it needs. After living for a while in an environment with sloppy headers, programs depend on things like obtaining declarations related to ANSI time functions by including <net/if.h>. (<net/if.h> used to expediently include <sys/time.h>; <sys/time.h> still expedniently includes <time.h>.) This is inherently unstable across time and across changing environments :-). >You state "most of the headers are only used in the kernel". While >you may be correct statistically, this is not a view I can endorse. >/dev/kmem makes a mockery out of these assumptions and a not New interfaces should use sysctl() and be designed better to only pass the parts of the kernel struct of interest to applications across the interface. >I did not enforce my philosophy blindly with these patches. You may >recall I started a weeks debate on this issue and at the >end if it, the concensus appeared to be strongly supportive of >the direction I have taken. The consensus seemed to be for self-sufficient headers. There was no consensus about how to implement this. >It wasn't philosophy driving engineering, though it has certainly >dictated the path I chose. The simple impetus was that code which >works perfectly well on all other major platforms refuses to compile >under FreeBSD for the very reason we have been discussing. From It must not be BSD code. FreeBSD has made very few changes to 4.4Lite's application interface (to a fault). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702010949.UAA17084>