[RFE] "nanoblackbox" feature that could be appealing for stable-binary-packages-driven distros

[jnpkrn]

So, having spent some time with logging/callsite section apparatus, I must
be wondering if such an obvious thing (now to me) has ever been considered:

• callsite section nicely puts the logging origins metadata into single array,
  i.e. something inherently indexable
• consider most volume of the logged messages come from the format
  member, i.e., the message template, which is moreover frequently the
  end form of the message to be logged (if not parametrized further)
• consider there's a mechanism to relatively uniquely identify the participants
  in the logging target chain incl. libqb itself, and admit a fair chance of
  being able to look the original binary (executable or library) based on
  that (Build ID note in the ELF structure?)

Then we can turn callsita metadata members + format parameters in
the original blackbox binary format into callsite identification + format parameters,
where based on the above, callsite identification equals unique identification of the binary + index to the callsite section (plus perhaps some more details
about the binary would be stored in the static header of the blackbox data
so as avoid brute force methods later on).

I assume that would be more space efficient, at the cost of added run-time
overhead and the risk of not being able to reconstruct the log journal truthfully
because of the original binary participants no longer existing, as the
reconstruction process fully depends on them being available. That's not
a big deal with distro-packaged software, though.

The idea is highly unelaborated, and there's more to it, such as when serializing
the callsite identification properly, it might be submitted also through syslog,
for instance, saving some space there. The point is: logs are mostly redundant
data, care just about the variable parts, possibly allowing for log throughput
increase, while still retaining the possibility of reconstructing the log stream
towards human readability later on, on demand.

And when already involving machinery so as to get to the actual log messages,
there are some further crossovers, such as with journal message catalogs that
go in the opposite direction of augmenting/explaining the particular messages...