On Sat, Mar 23, 2019 at 11:10:24PM +0530, Karuna Grewal wrote: > Thanks a lot Phil. This was lucid indeed. I still have a few more doubts: > * what's the purpose of a context (netlink or eval)? Contexts provide context. ;) E.g. nft_ctx holds application information like configured output/error file descriptors. In general, these context structures are used to provide data to functions further down in the call stack without the need for excessive amounts of function parameters or use of global variables (which should be avoided for obvious reasons). If you want to know more about where and how they are used, look up what fields are contained in each context struct and where they are instantiated. > * What is the purpose of the cache being used after the netlink message has > been already sent to the kernel? Cache belongs to nft_ctx, which is created by the application. The application may run multiple commands so keeping the cache after a commit to kernel is useful. I think it is used from echo callback as well, although I can't find an example right now. > * Could you please explain a bit about the kernel interaction once the > netlink message is sent esp. which structures store the data which was > carried by the message from userpace. I'm aware of the concept of hooks > being registered and thereon the processing is handled by the netfilter > code but I'm not completely clear about how the netlink message gets > handled internally. Libnftables objects (struct rule, struct chain, etc.) are converted into libnftnl objects (struct nftnl_rule, struct nftnl_chain, etc.) within libnftables. In libnftnl, there are *_build_payload() functions which serialize libnftnl objects into a netlink message identified by an instance of struct nlmsghdr. Netlink messages contain a static header (see struct nlmsghdr) and an arbitrary amount of attributes of the form [len, type, data]. Libnftnl uses libmnl to append those attributes to a message. In order to find out where and how a given netlink message is handled in the kernel, the quickest way is often to grep for some attribute type definition. One caveat with nlmsg attributes is that libnftnl and kernel have distinct ones. E.g. NFTNL_TABLE_NAME in libnftnl corresponds with NFTA_TABLE_NAME in kernel. See *_build_payload() functions in libnftnl for details, but in general NFTNL_FOO corresponds with NFTA_FOO in kernel. Cheers, Phil
