Hello Greg,

nice to see a detailed analysis, even if I argue against some points.

> 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.

This interface is meant to be used by one and only program, venus, isn't
it? So it is quite natural that the corresponding include belongs to Coda
source, where both the kernel module and the program live.

> 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.

Fortunately it is not the case.

Glibc has provisions for surviving kernel updates, so you do not need to
change the include files or recompile the library when you upgrade the
kernel.

> 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.

As said, it is not needed in case of Linux and glibc version skew.
So - why should the kernel install its interface? :-)
It's ok to install, and in some cases it is present, but better
we do not rely on this fact.

You are kind of thinking of source-oriented *BSD distributions, while a
system can be pretty much updateable in binary form, even in small pieces.
Many distributions, at least for Linux, use this possibility. I do *not*
say if it is "right" or "wrong".

> 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.

Great if you would package the Coda kernel part and do it properly!
(the word "module" does apparently mean more than one thing? what I tested
on FreeBSD was a kernel module, but may be not in "packaging sence"?)

Best regards Greg,
--
Ivan