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

That really seems messed up and asking for trouble.  How does anyone
ever compile anything and have it work?  Or are these types transformed
at the system call boundary?

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

My view is that having the /usr/include headers and the kernel not in
sync is a bug, and living in a world where they aren't is a
configuration nightmare.

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

We could certainly have a meta-header with m4 or something and build
OS-specific headers and merge those.

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

Right, but the API depends on the stability of various underyling types,
and if those change (as they did in BSD once) there's no programmatic
way to catch the error.  IIRC we changed something to uint32_t to
insulate the coda API from an underlying change.

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

The notion that libc provides coda.h without also providing the module
really seems just plain wrong and asking for trouble.  I would also hope
that the interface to the kernel isn't different for various kernels
(not sure if you mean version, or combination of debug features - in
NetBSD modules have to have the same DIAGNOSTIC setting as the kernel,
but this isn't an interface change to userland).  I can see the lkm not
being available for some cases, but that's different from changing the
messages that are sent if it is.  If libc is going to provide coda.h and
define the interface, then the approach I'd suggest is to use that
coda.h to compile the userland coda bits on GNU/Linux systems, both
venus and the kernel module.

In general .h files for modules is messy business.  The BSD tradition is
to have features be includable as regular kernel features (with 'options
foo' in a config file), and install the .h all the time.  Then, some
things can be built as modules (there are 40 in /usr/lkm from a system
build, including coda and the old coda interface), but the interface is
still defined in the standard way.

The BSD way for .h files is that the interface to the kernel (data
structures for system calls, ioctls, etc.) is defined in .h files which
are kept in the kernel sources.  As part of the overall system build,
those .h files are installed into /usr/include/sys, /usr/include/net,
and so on.  I said system build, but it's really part of the kernel
subpart of the whole build.  Applications then build against .h in
/usr/include, and thus match the running kernel.  Of course there are
binary compat issues when you build a program on one system and run it
on another, and this is dealt with by being careful not to change
interfaces unless really necessary, and then system calls and ioctls are
versioned, with the old codepoints not changing, and new codepoints for
the new structure variants.


In my view even on Linux the .h files that define kernel interfaces
should be part of kernel packages, not libc - there seems to be a
blurring of what's in a standard C library and what's OS specific.