From owner-freebsd-hackers Sat Feb 1 01:51:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA12670 for hackers-outgoing; Sat, 1 Feb 1997 01:51:37 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA12665 for ; Sat, 1 Feb 1997 01:51:34 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA17084; Sat, 1 Feb 1997 20:49:03 +1100 Date: Sat, 1 Feb 1997 20:49:03 +1100 From: Bruce Evans Message-Id: <199702010949.UAA17084@godzilla.zeta.org.au> To: bde@zeta.org.au, proff@iq.org Subject: Re: #include dependencies Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 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 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 , it must not define any identifiers start with `E' and followed by a digit or an upper case letter. If an application includes , 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 . ( used to expediently include ; still expedniently includes .) 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