Re: KLive: Linux Kernel Live Usage Monitor

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Aug 31, 2005 at 12:14:23PM -0700, tony.luck@intel.com wrote:
> Do you want to try to handle version skew ?  All kernels built
> from GIT trees look like 2.6.13 until Linus releases 2.6.14-rc1.
> Possible approaches (requiring changes to the kernel Makefile).
> 1) Use the SHA1 of HEAD to provide a precise identification.
> 2) Use $(git-rev-tree linus ^v${VERSION}.${PATCHLEVEL}.${SUBLEVEL}${EXTRAVERSION} | wc -l)
> to get an approximate distance from the base version
> 
> Another version issue is use of "localversion" ... I use it to tag
> kernels with a summary of the config file I used during build (e.g.
> -tiger-smp, or -generic-up).  Looking at the results you've collected
> so far, there appear to be a variety of other conventions in use
> that prevent aggregation of results.

Aggregation of results seems the biggest problem right now. If we add
the git tag we really have to aggregate the git revisions before showing
the main page (or there would be too many of them). So we need at least
a standard way to do that. Perhaps it's simpler to export it via
readonly sysctl or with /proc and passed separately to the server (not
mixed in the uname strings)? I can extend the protocol without
invalidating the old clients and old data.

I'm thinking to add optional aggregations for (\d+)\.(\d+)\.(\d+)\D and
for different archs. So you can watch ia64 only or 2.6.13 only etc...

The "-tiger-smp/-generic-up" makes life harder indeed ;).

If there was a more standard way to add extraversions and localversions
aggregation would be easier and more reliable.