Subject: Re: README: VFS change, breakings LKMs
To: Jaromir Dolecek <dolecek@ics.muni.cz>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: current-users
Date: 03/17/2000 10:27:46
On Fri, 17 Mar 2000, Jaromir Dolecek wrote:

> What about this ?
> 
> XXXXX
> Index: sys/mount.h
> ===================================================================
> RCS file: /cvsroot/syssrc/sys/sys/mount.h,v
> retrieving revision 1.82
> diff -u -p -r1.82 mount.h
> --- mount.h	2000/03/16 18:08:17	1.82
> +++ mount.h	2000/03/17 08:04:00
> @@ -344,6 +344,12 @@ struct vfsops {
>  #endif /* _KERNEL */
>  
>  /*
> + * VFS interface version number.
> + */
> +#define	VFS_VERSION	0x01
> +int	vfs_check_version __P((int));
> +
> +/*
>   * Flags for various system call interfaces.
>   *
>   * waitfor flags to vfs_sync() and getfsstat()

The problem here is you're versioning the VFS interface, when it is only a
small part of the problem. There are a number of changes we can make to
the VFS interface (obviously not the kind you just made) which would NOT
need such a versioning bump, like adding VOP's. Also, there are a number
of other parts of the kernel which, if changed, mean you need to recompile
the lkm anyway.  Like when we added fields to struct buf, all the file
systems needed a re-compile. 

I think what would work fine would be to bump the LKM version, and shove
__NetBSD_LKM_Version__ in it. On -current, __NetBSD_LKM_Version__ would
match __NetBSD_Version__. On the release branch, it would match the oldest
release which had the same interface. So if this had been around, 1.4 and
1.4.1 would have the same LKM version, while 1.4.2 would have a different
one.

If you attempt to load an old-version LKM, it could get the same behavior
as if you loaded an older __NetBSD_LKM_Version__ (but same LKM interface
version) LKM.

Take care,

Bill