Improve event formatting

[atenart]

Based on #385.

This introduces our own Formatter instead of directly using fmt::Formatter when constructing the event display result. The main advantage is an improved flexibility where formatting is not done at post-processing but directly while constructing the output. Event sub-sections and types can now decide to output multi-line data.

[amorenoz]

A couple of nits but otherwise, lgtm.

[amorenoz]

I found a possible corner case. I don't think it's related to this series but when I was testing it I happened to capture some drops on my wifi interface. These packets are probably some low level 802.11 frames so the skb fails to parse any metadata, everything is None except for packet.

Current main branch prints is as:
(replacing whitespaces with "·")

22465108813415·(0)·[irq/181-iwlwifi]·1675·[tp]·skb:kfree_skb·#146e90d4a667ffff8e8efdbff700·(skb·ffff8e8ee8afe200)
··

With this series, this event is printed as:

22465108813415·(0)·[irq/181-iwlwifi]·1675·[tp]·skb:kfree_skb·#146e90d4a667ffff8e8efdbff700·(skb·ffff8e8ee8afe200)
··

So, there are two extra lines at the end, not sure why but it seems related to this PR.

Also, the two spaces that are also present in main branch. I guess the issue is here:

          .try_for_each(|section| {
                write!(f, "{sep}")?;
                section.event_fmt(f, format)
            })?;

if a section writes 0 bytes we should not write "{sep}".

[atenart]

Thanks for the report and analysis. I however see a different root cause: sections are all expected to print an output (so far at least) but this is not true for the skb section if the protocol used is not supported. In such case the skb event is empty (except for the raw data) and nothing gets printed. This hides a bigger issue: the user has no idea what those packets are.

One option would be to display a warning if nothing was printed, eg "protocol not supported", but that leaves the user to wonder what this packet might be. Alternatively I think we can parse the eth header and at least provide this information (even if it was not requested) for packets we don't know how to handle. That will give a pointer to users about what this packet is.

diff --git a/retis/src/module/skb/bpf.rs b/retis/src/module/skb/bpf.rs
index 2978fbe0beb6..f1c23838335d 100644
--- a/retis/src/module/skb/bpf.rs
+++ b/retis/src/module/skb/bpf.rs
@@ -305,7 +305,9 @@ pub(super) fn unmarshal_packet(
                 unmarshal_l4(event, ip.get_next_header(), ip.payload())?;
             };
         }
-        _ => (),
+        // If we did not generate any data in the skb section, this means we do
+        // not support yet the protocol used. At least provide the ethertype.
+        _ => if event.eth.is_none() {
+            event.eth = Some(unmarshal_eth(&eth)?);
+        }
     }
 
     Ok(())

Which gives (for packets we don't know how to handle):

124073691061994 (0) [irq/178-iwlwifi] 1323 [tp] skb:kfree_skb #70d8283ef3f6ffff8c8f078dd680 (skb ffff8c91b1fda800) drop (reason NOT_SPECIFIED)
  if 4 (wlp82s0) 00:00:00:00:00:00 > 00:00:00:00:00:00 ethertype EAPOL (0x888e)

124075821479497 (0) [irq/188-iwlwifi] 1333 [tp] skb:kfree_skb #70d8a743b649ffff8c8f06082a80 (skb ffff8c916f8f3600) drop (reason mac80211_unusable/RX_DROP_U_REPLAY)
  67:00:00:a4:65:20 > 86:e4:00:e1:34:02 (0xc2c5)

An event better thing would be to only print the etype in such cases, but that makes things way more complex for not much value IMO.

I'll include the above by adding a commit (once #385 is merged as I'll have to rebase anyway).

[atenart]

Added a commit for generating an skb.eth section on unknown packets, reworked very slightly the prefix generation in the formatter (to support utf8 chars) and rebased on top of main. But really, not a lot of changes since v n-1.

[amorenoz]

As discussed offline, the issue I've raised is actually more complicated as for some reason a non-Ethernet packet is getting sent to retis (in particular it was a 802.11 frame). Let's tackle that in a different issue: #428.