Details
-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
None
-
9223372036854775807
Description
There is currently a strong linkage between the userspace tools and the kernel modules, in lustre.spec.in:
Requires: %{requires_kmod_name} = %{requires_kmod_version}
and this evaluates to a very specific kernel module package version, e.g.:
kmod-lustre-client = 2.14.0_7_gf7512cc
This dates back to commit 1.6.0-2717-gc7496eccfc, but that doesn't provide much explanation beyond "Tighten up some dependencies.", and the b=13908 is no longer available:
commit c7496eccfc6a4bc804bd999343a2d289d5e9eeaf
Author: brian <brian>
AuthorDate: Wed Apr 22 17:55:29 2009 +0000
Commit: brian <brian>
CommitDate: Wed Apr 22 17:55:29 2009 +0000
b=13908
i=yibin.wang
i=sheng.yang
Allow the name, version, kernel release and release of the lustre packages
to be defined on the command line.
With such a feature, actually properly name the patchless client packages in
our own build.
Tighten up some dependencies.
Such a strong binding between the user tools and the kernel modules is not really needed and could be relaxed significantly. Sticking within the same major release (e.g. ">= 2.14.0" in this case) would almost certainly be enough, with the caveat that not having new tools may limit access to some functionality that is available in the kernel (e.g. missing an "lfs" or "lctl" command to enable something, or an llapi_* function that was added later.
In theory, newer tools could also handle significantly older kernel module versions to some extent, but would typically be lacking in features from a newer release. In that regard, it doesn't really make sense for the user tools to require a newer version, but rather the kernel modules should require at least a minimum version of the tools in order to enable the new functionality. That said, maintaining some level of coherency between the tools and kernel modules makes sense, maybe within a few major release versions (+/- 0.3) to allow old interfaces to be slowly deprecated as needed.
