On 04/11/2018 10:03 AM, Pablo Neira Ayuso wrote: > On Wed, Apr 11, 2018 at 06:40:34AM +0200, Matthias Schiffer wrote: >> On 03/04/2018 12:16 PM, Matthias Schiffer wrote: >>> I noticed that more than 25% of binary size of libnftnl are made up of >>> snprintf functions. Having these in a library with the goal to abstract the >>> netlink interface of nftables seems questionable to me, but I have no idea >>> if it would be viable to move these functions to nft or to a separate library. >> >> As an experiment, I created a reduced version of libnftnl by ripping out >> all import/export functions and related code like buffer handling. This >> reduced the size of libnftnl.so from 155KB to 110KB (on x86-64, -Os, >> stripped, uncompressed), a reduction of roughly 30%. >> >> I would like to look into splitting libnftnl into two parts, which could be >> called libnftnl-core and libnftnl, to make nftables more suited for tiny >> embedded systems. All basic functions that do not deal with textual >> representations of rules (i.e. the reduced libnftnl I built) would be moved >> into libnftnl-core. >> >> Does this sound like a good idea, and would such a drastic change be >> acceptable for upstream inclusion, given the current libnftnl API can be >> preserved? > > Could you wrap the import/export code around the --with-json-parsing? > I mean, turn this into --with-json or such, so you can just compile > out that code, which is what is giving you the savings in terms of > size, right? > > I'm trying to keep it simple here :-) > If possible, I'd not only like to get rid of the JSON export support, but also the snprintf_default code; in short, anything dealing with human-readable rules, as this code is simply not necessary for a firewall application that just wants to configure rulesets. A libnftables without any printf support (i.e. without nftnl_ruleset_fprintf() etc.) would not be sufficient to run the nft CLI utility. In consequence, we (OpenWrt/Gluon) would need to ship two different flavous of libnftables: A "tiny" version for small devices, and a "full" version for users that want to use the nft CLI to read/write the low-level rules. Separating libnftnl into a core library and an import/export library used by nft seems like better software design to me than adding more configuration switches. Kind regards, Matthias
Attachment:
signature.asc
Description: OpenPGP digital signature
