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 :) -- 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
