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.
Any opinions in this posting are my own and not those of my present
or previous employers.