]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MEDIUM: log: carry tag context in logformat node
authorAurelien DARRAGON <adarragon@haproxy.com>
Thu, 22 Feb 2024 19:20:41 +0000 (20:20 +0100)
committerAurelien DARRAGON <adarragon@haproxy.com>
Thu, 4 Apr 2024 17:10:01 +0000 (19:10 +0200)
commit7d8f45b6471984fedd7153e842de9baa03d8f669
tree181948f023b4a812a0ea2a46759ab148c4961373
parent8cf5c3d7f0ad83c2fab48a5d482b038b1cbe4efc
MEDIUM: log: carry tag context in logformat node

This is a pretty simple patch despite requiring to make some visible
changes in the code:

When parsing a logformat string, log tags (ie: '%tag', AKA log tags) are
turned into logformat nodes with their type set to the type of the
corresponding logformat_tag element which was matched by name. Thus, when
"compiling" a logformat tag, we only keep a reference to the tag type
from the original logformat_tag.

For example, for "%B" log tag, we have the following logformat_tag
element:

  {
    .name = "B",
    .type = LOG_FMT_BYTES,
    .mode = PR_MODE_TCP,
    .lw = LW_BYTES,
    .config_callback = NULL
  }

When parsing "%B" string, we search for a matching logformat tag
inside logformat_tags[] array using the provided name, once we find a
matching element, we craft a logformat node whose type will be
LOG_FMT_BYTES, but from the node itself, we no longer have access to
other informations that are set in the logformat_tag struct element.

Thus from a logformat_node resulting from a log tag, with current
implementation, we cannot easily get back to matching logformat_tag
struct element as it would require us to scan the whole logformat_tags
array at runtime using node->type to find the matching element.

Let's take a simpler path and consider all tag-specific LOG_FMT_*
subtypes as being part of the same logformat node type: LOG_FMT_TAG.

Thanks to that, we're now able to distinguish logformat nodes made
from logformat tag from other logformat nodes, and link them to
their corresponding logformat_tag element from logformat_tags[] array. All
it costs is a simple indirection and an extra pointer in logformat_node
struct.

While at it, all LOG_FMT_* types related to logformat tags were moved
inside log.c as they have no use outside of it since they are simply
lookup indexes for sess_build_logline() and could even be replaced by
function pointers some day...
include/haproxy/log-t.h
src/log.c