When one modifies the kernel, and changes a structure definition that
affects an interface, installing the kernel needs to install the new
.h so that programs can be rebuilt for the new interface.

In BSD, the kernel include files (things in
/usr/include/{sys,net,netinet}, basically) are in the kernel sources,
and 'make includes' in /usr/src puts them in place.  I have done this
a number of times, changing struct ifnet, adding ioctls, etc. and it
has proved to be a very sensible way.

  I don't know how it precisely works with FreeBSD and NetBSD. But in my
  experience, the /usr/include/linux/coda.h 'kernel header' is taken from
  whatever kernel glibc was linked against.

It sounds like /usr/include/linux/coda.h is in the glibc package,
rather than the kernel package.  This seems like an incorrect
practice, or at least it imposes a restriction that one can't change
kernels or modify a kernel without updating to a corresponding glibc
package.

  So the actual coda.h of the running kernel is typically not (easily)
  available unless someone installs special additional packages, or
  compiles their own kernel, and in both cases finding the location of the
  kernel sources isn't very uniform.

This is messy, and why the kernel should install its interface
definitions in the standard place - just like libfoo installs not only
libfoo.a but also /usr/include/foo/foo.h to link against.

  In other words, for most Linux distributions it is easier to ship our
  own copy in the Coda sources and use the CODA_KERNEL_VERSION to perform
  a run-time check whether everything matches.

OK, so I see that this is intractable on Linux.  That probably
explains why the coda include file is not handled correctly on
NetBSD.  But, this means that the CODA_KERNEL_VERSION has to match the
entire interface, and if the .h and the implementation are seperate
then we need a protocol definition.  Sorry to be ranting, but Coda is
in a difficult middle ground - parts of the system are in different
places, but it's not a full-blown protocol with independent
interoperable implementations.

So, perhaps I can get coda.h installed on NetBSD and perhaps FreeBSD,
and then the coda sources can use it if present
(/usr/include/coda/coda.h, I think), and if not use the one that comes
with.  This makes the compat stuff for with/without realms harder,
though.

Perhaps coda support should be removed from the BSD base systems and
have to be a module, like xfs for arla.  That would address the
.h/code consistency issue.

        Greg Troxel <gdt_at_ir.bbn.com>