Date: Sat, 1 Feb 1997 19:15:32 +1100 (EST) From: Julian Assange <proff@iq.org> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: #include dependencies Message-ID: <199702010815.TAA06303@profane.iq.org> In-Reply-To: <199701311937.GAA29276@godzilla.zeta.org.au> from Bruce Evans at "Feb 1, 97 06:37:11 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Most of the #include changes are wrong. > > Most of the headers are only used in the kernel. Kernel sources > follow the convention of including <sys/param.h> or <sys/types.h> > before any other header. > > Bruce I'm aware of this, this is why you see a number of #ifndef KERNEL. I strongly philosophically disagree with the need for this but have done so out of what appears to be (foolish imho) tradition. At first I thought perhaps this step was due to cross-compilation 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. 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 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. I have only resolved mandatory dependencies; i.e those dependencies required for gcc to parse the include file without error, which any C code that uses the include file MUST have resolved, one way or the other, in order to compile at all. 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 insignificant number of user level programs can and do parse kernel data structures just this way. As time goes by and boundaries between user-level programs the kernel break down we can only expect the cross-transfer of data-structures to increase. Personally I believe the only #ifdef KERNEL we should be seeing is around externs and function definitions, because that is where the only REAL difference between user-level and kernel-level include code dependencies should be occurring. 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. 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 very large, well supported and well ported user-level programs like scilab to kernel/lkm code such as ipfilter. I believe the -hackers archive bears me out on this. Comments? Cheers, Julian <proff@iq.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702010815.TAA06303>