On Wed, Aug 04, 2004 at 09:53:25AM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> 
> > On Mon, Aug 02, 2004 at 08:19:08PM -0400, Greg Troxel wrote:
> > > Just to make my long-ranted point again: the kernel header for coda.h
> > > is the definition of the kernel interface, and this should be
> > > maintained with (and compiled with) the kernel code, and installed
> > > under /usr/include someplace _by the kernel_.  Coda userland should
> > 
> > But on Linux it is, however it is not related to the current kernel but
> > depends on whatever kernel version libc was built against. I guess it is
> > done so differently because there is no equivalent to 'make world'.
> 
> OK, so if they do it that way having a libc version installed that
> doesn't match/wasn't compiled with the the running kernel version is
> simply broken and must be avoided.  That's a natural consequence of
> one package defining interfaces for another.

Not completely... it's been stated several times that the userland 
interface to the kernel is the syscall interface, and that this
interface WILL be stable. The latest was by Andrew Morton at the Ottawa
Linux symposium that new syscalls may be added, but nothing will be
removed. This also applies to any values that passed as arguments to
syscalls.

Regarding the coda.h kernel interface, is it not sufficient to have the 
'CODA_KERNEL_VERSION' define?

The only time I've had issues and problems with glibc (and userland
headers) being compiled against a different kernel when you are running
is when there are new features added that you want to use. (such as
NPTL)

The other issue is poorly-designed systems with userland and kernel
components that don't properly versionate, or are just poorly
implemented. But I don't feel like coda has this problem.