On Wed, Dec 14, 2005 at 12:31:00PM -0500, Jeffrey Hutzelman wrote: > > > On Wednesday, December 14, 2005 09:04:57 AM -0500 Tom Keiser > <[EMAIL PROTECTED]> wrote: > > >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) > > Indeed, this is not what the CML version number is for, and overloading it > for that purpose is a bad idea. I've had too many bad experiences with > software that breaks because it insists on exact matching of software > version numbers instead of using interface versions.
How about we just dump the CML version as informative info. I have a patch available here: http://source.scl.ameslab.gov/hg/openafs-misc-fixes?cmd=changeset;node=df929d0767ee2d295c4b0c3139a0aebd9dc37fae that does this: With matching versions: MODLOAD-2.6.14-1-powerpc-SP# ../../afsd/afsd afsd: All AFS daemons started. With mismatched versions: MODLOAD-2.6.14-1-powerpc-SP# insmod ./libafs.ko MODLOAD-2.6.14-1-powerpc-SP# ../../afsd/afsd afsd: @(#) OpenAFS 1.4.1-rc2 built 2005-12-13 hg-b95a152f628d+ tip libafs: @(#) OpenAFS 1.4.1-rc2 built 2005-12-14 hg-b95a152f628d+ tip afsd: All AFS daemons started. If we add this extra informative information, it will be much easier to figure out what people are actually running.. In my case, I'm going to keep this in my mercurial tree so I know exactly what source code was used to create the binaries. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
