[Bug translator/13156] New: improve hash_XXX.log

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13156

             Bug #: 13156
           Summary: improve hash_XXX.log
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


We generate a FOO_hash.log text file in the module cache to sort of document
how the hash value came to be.  (PR9931).  This has not quite lived up to its
potential though as the hash.log file does not name the values.  For example,
some random script's log contains:

[Wed Aug 31 10:28:36 2011] script_hash:
2.6.38.8-35.fc15.x86_64
/lib/modules/2.6.38.8-35.fc15.x86_64/build
4096
1312128479
x86_64
/lib/modules/2.6.38.8-35.fc15.x86_64/build/.config
114130
1309961071

where each number / string is the data that got munged into the overall hash,
but lacks a name to document it.  It would be nice if the hash.cxx parm_stream
bits were extended so that some metadata were made available.  One way would
be to extend all the hash::add* member functions to take an extra description
string, and paste that only into the parm_stream.  Another way would be to 
add a single function hash::describe(const string&) that adds the given
string to the parm_stream only (and not to the md4 state), to be used thusly.
e.g. get_base_hash():

+ h.describe("kernel relase:");
  h.add(s.kernel_release);
+ h.describe("kernel build tree:");
  h.add_path(s.kernel_build_tree);
+ h.describe("arch:");
  h.add(s.architecture);

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.