From: Rusty Russell <rusty@au1.ibm.com>

The way it works is that the .mod file contains the name of the module (as
before), but succeeding lines are the constituent parts (assumed to be .c
files, which usually works: if they use MODULE_VERSION in a file for which
this isn't true we'll get a warning).

As we postprocess modules, we look in the .modinfo section for a
"version=", which is placed by the MODULE_VERSION() macro.  This will be of
form "version=<macroarg>" "\0" [24 chars] "\0".  The 24 chars are replaced
by the md4 sum of the .c files and any files they #include using '#include
"file"' which are found in the current directory.  Whitespace is collapsed
outside strings, and comments are ignored for purposes of the sum.

The result is a .modinfo entry such as

	version=1.16ac-rustytest B13E9451C4CA3B89577DEFF



At the kernel summit, various people asked for a MODULE_VERSION macro to
store module strings (for later access through sysfs).  A simple md4 is
needed to identify changes in modules which, inevitably, do not update the
version.  It skips whitespace and comments, and includes #includes which
are in the same dir.

The module versions should be set according to this definition, based on
the RPM one, or CVS Revision tags.  Violators will be shot.

 [<epoch>`:']<version>[`-'<extraversion>]
 <epoch>: A (small) unsigned integer which allows you to start versions
          anew. If not mentioned, it's zero.  eg. "2:1.0" is after
     "1:2.0".
 <version>: The <version> may contain only alphanumerics.
 <extraversion>: Like <version>, but inserted for local
          customizations, eg "rh3" or "rusty1".

Comparison of two versions (assuming same epoch):

Split each into all-digit and all-alphabetical parts.  Compare each one one
at a time: digit parts numerically, alphabetical in ASCII order.  So 0.10
comes after 0.9.