Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > @@ -98,7 +98,11 @@ static const struct symbol_table ct_status_tbl = {
> > SYMBOL("confirmed", IPS_CONFIRMED),
> > SYMBOL("snat", IPS_SRC_NAT),
> > SYMBOL("dnat", IPS_DST_NAT),
> > + SYMBOL("seq-adjust", IPS_SEQ_ADJUST),
> > + SYMBOL("snat-done", IPS_SRC_NAT_DONE),
> > + SYMBOL("dnat-done", IPS_DST_NAT_DONE),
>
> These will be now exposed through 'ct status' forever, not sure we
> have a usecase to allow users to match on this.
I don't. Its so ct status is pretty printed here:
trace id 32 t INPUT conntrack: ct ... ct status dnat-done ...
I can see if I can somehow restrict this to the trace display side.
OTOH I don't see a reason to artificially limit this.
> I know these are exposed through uapi, but I don't have a usecase for
> them to allow users to match on them.
I don't have that either. But I don't see why we should prevent it.
> If we go for exposing these flags through ct status, do you think it
> is possible to provide terse description of these "new flags" in the
> manpage?
Sure, will add.
> > --- a/src/netlink.c
> > +++ b/src/netlink.c
> > @@ -2116,6 +2116,114 @@ next:
> > }
> > }
> >
> > +static struct expr *trace_alloc_list(const struct datatype *dtype,
> > + enum byteorder byteorder,
> > + unsigned int len, const void *data)
>
> Suggestion, not deal breaker: It would be good to start a new
> src/trace.c file to add this and move tracing infrastructure?
OK, let me respin this after splitting the existing stuff to trace.c.
Thanks for reviewing!
