Message ID | 20220120000402.916332-1-pablo@netfilter.org |
---|---|
Headers | show |
Series | add description infrastructure | expand |
Hi Pablo, On Thu, Jan 20, 2022 at 01:03:59AM +0100, Pablo Neira Ayuso wrote: > This is my proposal to address the snprintf data printing depending on > the arch. The idea is to add description objects that can be used to > build the userdata area as well as to parse the userdata to create the > description object. I tried to integrate this into nftables, but failed to understand how this all is supposed to come together: In nftables, concat is treated like any other expression. Your series seems to require special treatment? At least there are separate "desc" data structures for each. It seems like one can't just replace build_udata callbacks to populate an nftnl_expr_desc object? Cheers, Phil
On Thu, Mar 10, 2022 at 12:35:57PM +0100, Phil Sutter wrote: > Hi Pablo, > > On Thu, Jan 20, 2022 at 01:03:59AM +0100, Pablo Neira Ayuso wrote: > > This is my proposal to address the snprintf data printing depending on > > the arch. The idea is to add description objects that can be used to > > build the userdata area as well as to parse the userdata to create the > > description object. > > I tried to integrate this into nftables, but failed to understand how > this all is supposed to come together: In nftables, concat is treated > like any other expression. Your series seems to require special > treatment? The idea is that you build the nftnl description object either from the set typeof expression or the set datatype (depending on how the user has defined the set). > At least there are separate "desc" data structures for each. > It seems like one can't just replace build_udata callbacks to populate > an nftnl_expr_desc object? You can use the description object in two ways: - build_udata is called when setting the libnftnl set udata field, to build it. - you pass the description object to snprintf. The existing code to build the userdata TLV that resides in nftables should go away and use this new infrastructure, I'm basically moving to libnftnl the existing nftables code to build the set userdata area.
Hi Pablo, On Thu, Jan 20, 2022 at 01:03:59AM +0100, Pablo Neira Ayuso wrote: > This is my proposal to address the snprintf data printing depending on > the arch. The idea is to add description objects that can be used to > build the userdata area as well as to parse the userdata to create the > description object. > > This is revisiting 6e48df5329ea ("src: add "typeof" build/parse/print > support") in nftables which adds build and parse userdata callbacks to > expression in libnftables. My proposal is to move this to libnftnl. Looking at your PoC again, I assume it was meant for use by applications to create and populate an nftnl_set_desc object and serialize it into nftnl_set's userdata using nftnl_set_desc_build_udata(). Since the information is needed within libnftnl though, the whole API does not make sense anymore and nftnl_set_desc must be serialized by libnftnl itself. This in turn means one may just integrate the data structure into nftnl_set's 'desc' field directly and extend nftnl_set_set_data() to allow populating the new fields, plus nftnl_set_desc_add_{expr,datatype}() I guess. Am I on the right track there? Maybe it's quicker for me to add the missing bits to my stuff instead of adjusting it to your series after making it work for the intended purpose. Especially since I'm not quite sure what goal we're trying to achieve. Cheers, Phil
On Wed, Apr 06, 2022 at 01:06:13PM +0200, Phil Sutter wrote: > Hi Pablo, > > On Thu, Jan 20, 2022 at 01:03:59AM +0100, Pablo Neira Ayuso wrote: > > This is my proposal to address the snprintf data printing depending on > > the arch. The idea is to add description objects that can be used to > > build the userdata area as well as to parse the userdata to create the > > description object. > > > > This is revisiting 6e48df5329ea ("src: add "typeof" build/parse/print > > support") in nftables which adds build and parse userdata callbacks to > > expression in libnftables. My proposal is to move this to libnftnl. > > Looking at your PoC again, I assume it was meant for use by applications > to create and populate an nftnl_set_desc object and serialize it into > nftnl_set's userdata using nftnl_set_desc_build_udata(). Since the > information is needed within libnftnl though, the whole API does not > make sense anymore and nftnl_set_desc must be serialized by libnftnl > itself. This in turn means one may just integrate the data structure > into nftnl_set's 'desc' field directly and extend nftnl_set_set_data() > to allow populating the new fields, plus > nftnl_set_desc_add_{expr,datatype}() I guess. > > Am I on the right track there? > > Maybe it's quicker for me to add the missing bits to my stuff instead of > adjusting it to your series after making it work for the intended > purpose. Especially since I'm not quite sure what goal we're trying to > achieve. Goal is to consolidate code. Move the existing code in nftables to libnftnl so there is a desc object that can be use to build the userdata and to all assist the libnftnl print functions. This will take a bit of work.