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 > <[EMAIL PROTECTED]> wrote: > > >Horst Birthelmer <[EMAIL PROTECTED]> 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 upgrades > >when you're using OS packages more difficult if the versions have to match > >exactly and normally it works fine. Usually the kernel module is in its > >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 like > >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. Would it be better to use call_syscall(), or a pioctl to get the kernel module version string for this? While maintaining compatibility is nice in theory, in practice, this is something that nobody ever tests until a user reports a weird crash. If there was a test suite that got run to maintain compatability, I would argue it's worth it. But when we wind up advising users to make sure the kernel and userspace versions match, we should at least help them out and tell them what's going on. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
