Re: [PATCH nftables 6/6] src: add trace support to nft monitor mode

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Nov 24, 2015 at 11:07:41AM +0000, Patrick McHardy wrote:
> On 24.11, Pablo Neira Ayuso wrote:
> > On Tue, Nov 24, 2015 at 10:58:16AM +0000, Patrick McHardy wrote:
> > > On 24.11, Florian Westphal wrote:
> > > > > An alternative would be to use our internal datatypes, IOW parse the
> > > > > attributes, associate the values with an internal type and use the regular
> > > > > printing functions. The benefit would be fully consistent output, also
> > > > > with respect to output options like numerical output.
> > > > 
> > > > 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.
> > 
> > What we did do far is to have the fprintf variant for quick printing,
> > but this should be based on the printing to buffers. Both approaches
> > would be exported.
> > 
> > Does this sound good to you?
> 
> I'm completely fine with the fprintf printing *for libnfntnl*, but I'm
> questing whether nft should make use of it for its own output asides from
> debugging netlink operations. I also wouldn't consider the libnftnl output
> stable in any form, the fprintf variant it basically something for debugging,
> at least I've always seen it that way.

Oh I see, you were refering to nft, that makes sense to me.

> So yeah, I'm not opposed to having it, just to using it for this particular
> purpose.

Thanks for your feedback, sorry if I'm insisting much, I just want to
make sure we get all the same picture in our heads :)