On Fri, Nov 17, 2023 at 1:10 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Fri, 2023-11-17 at 15:31 -0500, Andrii Nakryiko wrote:
> [...]
> > > > I think this implementation has an undesired surprising behavior.
> > > > Imagine you have a log like this:
> > > >
> > > > A
> > > > C
> > > > D
> > > > B
> > > >
> > > > And you specify
> > > >
> > > > __msg("A")
> > > > __nomsg("B")
> > > > __msg("C")
> > > > __msg("D")
> > > > __msg("B")
> [...]
> > I think it's useful in general, I believe I had few cases where this
> > would be helpful. So submitting separately makes sense. But I think
> > this patch set doesn't need it if we can validate logic in last patch
> > without relying on this feature.
>
> Ok, will do it separately. While at it can also add two more features:
> - __msg_next, again mimicking FileCheck [0], which would require match to
> be on a line subsequent to previous match;
> - __msg_re, with support for regular expressions (using [1]).
>
> [0] https://llvm.org/docs/CommandGuide/FileCheck.html
> [1] https://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html
So far this patch set didn't have conflicts with bpf-next and
we need to land it in the bpf tree and backport later,
so pls minimize the changes.
_nomsg, _msg* extensions are certainly useful, but let's add them
later via bpf-next when trees converge.
