On Mon, May 21, 2007 at 07:44:23AM -0400, Greg Troxel wrote:
> There's another longstanding build system mess that I'd like to point
> out again.   There is a coda.h that defines the interface to the
> kernel.  When the kernel is implemented by a module, that file should be
> part of the module sources, and installed someplace in the system along
> with the module, so that programs not in the coda source tree can use
> the interface definition.
> 
> When the kernel is implemented by code in the kernel sources, then the
> operating system itself should provide coda.h in a standard place, and
> the venus/vice sources should use that .h.  Right now we have separate
> maintenance of the .h and the implementation and don't build them
> against each other, which is just madness, because we give up all the
> type checking that would be available.

Having kernel and userspace headers separate is I guess a Linux
tradition. A uid_t in kernel space may be 16-bits, while the userspace
type is 32-bits, or the other way around. Linux libc's provide a cleaned
up copy of the kernel headers of the kernel it was built against and is
responsible for mapping between kernel and userspace types. Part of the
reason is probably because there is no 'make buildworld' equivalent, and
userspace and kernel are not necessarily in sync.

The current coda.h header as included in the Linux kernel probably
wouldn't ever get merged with the current rules for inclusion, as it
contains various BSD, Solaris and cygwin specific ifdefs which are
definitely not Linux kernel specific. In the end, the typechecking comes
down to keeping the API as stable as possible and giving userspace a way
to identify which version it is using, or to query which version the
kernel is using, when it opens the Coda device.

I'm not really sure how to fix it correctly, but that is because I know
little about the BSD way of doing things. It is definitely not kosher on
a Linux system to have a separately built Coda kernel module overwrite
the libc provided linux/coda.h header, or really to put any header in
/usr/include because this kernel module may be built only for one of the
possible kernels that the system may boot from and the Coda client
shouldn't be tied to only work for that one specific kernel.

Jan