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

Well, natural is in the eye of the beholder.  To me, it is natural
that the code implementing the interface and the interface be kept
together and under consistent configuration management. 

The 'kernel module' does not appear to live in the coda sources.  The
BSD code that used to be there was ancient, and the sources for the
kernel part that everybody uses for FreeBSD and NetBSD are (and have
been) in the FreeBSD and NetBSD base kernel sources.  I don't know
where the Linux coda kernel sources are.

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

Sure, but in a binary system you would have the kernel and the
'kernel-dev' package which would provide headers used to build
programs that call the kernel.  Binary packaging still has the same
fundamental configuration management concerns.  System calls are
really just like function calls, excpet they have cross-address space
and privilege semantics as well.

  > 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"?)

Well, sources would be in the coda CVS module, and the build on each
system would have to build the right module.  But this would be a lot
of work, and I don't think the gains justify it.

I was using 'module' to refer to a part of the kernel that is
dynamically loaded, with modload, kldload, or something like that.
These can be compiled from code that is in-tree, or out of tree, the
latter like AFS's arla.  With in-tree code, changing versions is much
harder, unless you require people to patch their kernels as they
switch venus versions.

Anyway all this discussion has been very helpful to me, and I finally
have an idea of how to deal with version upgrading in NetBSD
(presumably FreeBSD and OpenBSD could copy this, but I've been reading
NetBSD kernel code more recently):

  Arrange for sys/coda/coda.h to be installed in /usr/include/coda

  put "/* #define CODA_NO_REALMS */" in coda/coda.h

  Edit coda/coda.h for the new structures and version #,
  conditionalized on CODA_NO_REALMS to get the old structures/version.

  Modify the code, conditionalized as well, to produce the realms
  behavior.

This way, once this change is committed, the default will be that
non-realms venus will fail (version check).  But people who want that
can edit one file and rebuild their kernel and run the old venus.

Using /usr/include/coda/coda.h instead of the included one will enable
compile-time checking of interface version.  Of course, run-time
version checking is still needed if binaries are moved around, such as
via package systems.


I should point out that while this is an issue with the realms change,
the venus/kernel interface has been very stable over the years.  So
this is much less of an issue because it isn't expected to recur
yearly.