On 24.11, Florian Westphal wrote: > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > > Yes, right now virtually all of the printing is in libnftnl > > > (called from nftables via nftnl_trace_fprintf() ). > > > > The downside is that we're stuck to fprintf. I'm working on moving nft to > > printing to buffers for pretty printing, intending set contents, sorting > > flow tables in different dimensions etc. If we have external printing we'll > > be missing some flexibilty in handling it, also regarding logging to other > > outputs than stdout. > > The _fprint variant is a convenience wrapper for nftnl_trace_snprintf. > Would that work for you? Probably, but with downsides. The nft internal buffer printing will encapsulate every printed element so we can reorder them based on an abstract meaning, f.i. for pretty printing, where we want to keep related things together and reindent other parts. We can also do filters, sorting on individual parts both numerically and lexically, structured output etc etc, but all that requires to have the invidual parts of the output available seperately. So yeah it would work, and at least the sorting part doesn't make sense for tracing anyways, but it would be a special case with some limitations. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
