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. So yeah, I'm not opposed to having it, just to using it for this particular purpose. -- 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
