Re: [PATH nft v2 05/18] libnftables: add nft_run_command_from_buffer

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Aug 21, 2017 at 10:23:44AM +0200, Pablo Neira Ayuso wrote:
> On Sat, Aug 19, 2017 at 05:24:07PM +0200, Eric Leblond wrote:
> > Signed-off-by: Eric Leblond <eric@regit.org>
> > ---
> >  include/nftables/nftables.h |  3 +++
> >  src/libnftables.c           | 26 +++++++++++++++++++++++++-
> >  src/main.c                  | 19 ++++++++-----------
> >  3 files changed, 36 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/nftables/nftables.h b/include/nftables/nftables.h
> > index cfa60fe..63150ba 100644
> > --- a/include/nftables/nftables.h
> > +++ b/include/nftables/nftables.h
> > @@ -20,4 +20,7 @@ void nft_global_deinit(void);
> >  struct nft_ctx *nft_context_new(void);
> >  void nft_context_free(struct nft_ctx *nft);
> >  
> > +int nft_run_command_from_buffer(struct nft_ctx *nft, struct nft_cache *cache,
> > +				char *buf, size_t buflen);
> 
> Can we probably have something like:
> 
> nft_import_from_buffer(ctx, ...)
> nft_import_from_file(ctx, ...)
> 
> That initializes the context structure. Then, a generic:
> 
> nft_run(ctx)
> 
> I suggest you make a patch to add these to nftables in first place.
> I mean, just send a patch that adds these functions as static to
> src/main.c to start with it. Just as a cleanup to prepare thing, we
> can integrate this asap meanwhile we keep discussing library details,
> so we reduce the size/burden of your patchset as we iterate over it.
> To integrate things more quickly.

Actually, every nft_import_xyz() would just provide the batch support
we need, ie. it should be possible to call nft_import_xyz() several
times before we call nft_run().

The nft_import_xyz() calls would to the scanner, parsing and
evaluation phases.

The nft_run(nlsock, ...) would just push this into the kernel - so
this function would be wrapping the netlink layer handling...

I would say this nft_run() become nft_compile() instead and we take
the underneath netlink codebase to do the handling away from this...

Otherwise, we will have to add branches to deal with non-blocking IO.

Then, at some point to start looking like libnl... and that is not
good ;-)

I can help with preparation patches, let's just agree on what needs to
be done so we don't overlap each other.

Thanks!