[OpenAFS-devel] afsd & libafs module version checking??
Tom Keiser
tkeiser@gmail.com
Wed, 14 Dec 2005 09:04:57 -0500
On 12/14/05, Troy Benjegerdes <hozer@hozed.org> wrote:
> On Sat, Dec 10, 2005 at 02:37:19PM -0500, Jeffrey Hutzelman wrote:
> >
> >
> > On Saturday, December 10, 2005 10:51:05 AM -0800 Russ Allbery
> > <rra@stanford.edu> wrote:
> >
> > >Horst Birthelmer <horst@riback.net> writes:
> > >>On Dec 10, 2005, at 5:13 AM, Troy Benjegerdes wrote:
> > >
> > >>>Is there a good way we can put a version string in both afsd and the
> > >>>kernel module, and spit out a warning if they are mismatched?
> > >
> > >>I heard this many times in the past ;-)
> > >
> > >>It's just nobody did it yet.
> > >
> > >You also don't want the checking to be too tight, since it makes upgra=
des
> > >when you're using OS packages more difficult if the versions have to m=
atch
> > >exactly and normally it works fine. Usually the kernel module is in i=
ts
> > >own separate package, and since you want to be able to have multiple
> > >kernel modules for different kernels installed at the same time, it's =
a
> > >bit tricky to ship afsd in the same package as the kernel module.
> > >
> > >Ideally, the interface should be backward-compatible, since it's not l=
ike
> > >we change the parameters often, but that may be too much work.
> >
> > In all of the recent cases I know of where there have been incompatible
> > changes in the afsd/libafs interface, backward compatibility would not =
have
> > been difficult. That it wasn't done was the result of unfortunate
> > misjudgement, rather than any particular technical difficulty.
>
> Well, at the least, I'd like to have afsd compare the cml_version_number
> strings with the kernel module and print a warning if they don't match.
>
Basing this on cml_version_number has a few disadvantages:
(1)compile date becomes part of the decision
(2)autoconf flags cannot change syscall and ioctl interface behavior
(3)it's overly brittle; the kernel interfaces shouldn't be assumed to
change between every minor revision
(4)because of the packaging issues Russ brought up, we would end up
sending spurious warnings to users (who would probably send in
unnecessary bug reports)
Instead, I'd propose we define a monotonically increasing kernel
interface version counter that gets incremented by the developer
whenever backwards-incompatible changes are made to a syscall or ioctl
interface. Even this seems a bit harsh since a change to an
afsd-specific syscall would cause the fs command to issue warnings.=20
Should there instead be a few version counters that codify stability
of different subsets of the kernel interfaces in a way that is
meaningful to our userspace apps (e.g. common interfaces,
afsd-specific interfaces, inode interfaces, pioctl interfaces, etc.)?
> Would it be better to use call_syscall(), or a pioctl to get the kernel
> module version string for this?
>
Personally, i'd rather see it added as a syscall since you're not
dealing with a path. Regardless, the version query interface should
be defined carefully, and declared immutable.
--
Tom Keiser
tkeiser@gmail.com