Date: Sat, 1 Feb 1997 16:50:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: proff@iq.org (Julian Assange) Cc: bde@zeta.org.au, hackers@freebsd.org Subject: Re: #include dependencies Message-ID: <199702012350.QAA06912@phaeton.artisoft.com> In-Reply-To: <199702010815.TAA06303@profane.iq.org> from "Julian Assange" at Feb 1, 97 07:15:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
I'm going to skirt the periphery of this argument. I think the point being debated may very well be "the wrong point", since it seems to assume some things which themselves assume continued bad interface design on the part of kernel engineers... > > 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. > > 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. The typical use of the _KERNEL manifest value checks is to allow a single header file to define an interface, AND an implementation. The interface is user space, and the implementation is kernel space. Typically, you will also see this for exposed kernel data structures, such as those incorrectly used in 'ps', 'w', and so on, causing their dependency on things like the proc structure layout, which should be opaque to them. > 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. Any structure that is used in the kernel and is not "#ifndef _KERNEL" excepted, is defining reading that structure out of /dev/kmem as an accepted interface. I think that exposing the kernel internals this way is a *bad* idea, since it increases the number of programs that will potentially need to be recompiled as a result of a kernel change, and this is a bad thing. Typically, there should be an interface for the data passed across a kernfs and/or procfs, and the data structure for passing this data should remain fixed, regardless of the implementation structure being changed to accomodate ongoing developement. The single failure case for this is running the programs against a kernel core file. This is probably not an issue that should be perpetuated. It is the responsibility of the kernel debugger to provide these utilities. Preferrably, it will do so at some point by the kernel being implemented in ELF, and there being debugging segments which are run by the debugger, but not loaded by the kernel loader, which are loaded into the debugger as modules specific to the kernel file being debugged... after all, you can not debug a kernel core without the kernel file from which the core originated, and you might as well take advantage of this. As an alternative to kernfs/procfs interfaces, which would tend to pollute the kernel with useless-to-the-kernel code and data, the 'ps', 'w', and so on could query for the kernel image file with sysctl if an image file is not provided, and similarly, load these interpretation and iteration modules. The 'ps', 'w', and so on would then be able to continue to take a core and image argument, as now, but the ability to use the information contained in the core would not depend on the recompilation of the utilities. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702012350.QAA06912>