[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170626170219.GA10628@salvia>
Date: Mon, 26 Jun 2017 19:02:19 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Florian Westphal <fw@...len.de>
Cc: Lin Zhang <xiaolou4617@...il.com>, kadlec@...ckhole.kfki.hu,
davem@...emloft.net, linux-kernel@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next] netfilter: conntrack: add a new
NF_CT_EXT_EXPAND extension
On Mon, Jun 26, 2017 at 06:53:09PM +0200, Florian Westphal wrote:
> Lin Zhang <xiaolou4617@...il.com> wrote:
> > In the current conntrack extend code, if we want to add a new
> > extension, we must be add a new extension id and recompile kernel.
> > I think that is not be convenient for users, so i add a new extension named
> > NF_CT_EXT_EXPAND for supporting dynamic register/unregister expansion
> > in runtime that means if kernel support NF_CT_EXT_EXPAND extension,
> > user could call nf_ct_expand_area_add() to register a new expansion
> > but not need to predefine an id in enum nf_ct_ext_id.
>
> We never did this because its only required for out of tree modules.
>
> I would prefer if such extensions are discussed/proposed on nf-devel
> instead, and then, if there is agreement that the extension is useful,
> it can be submitted for inclusion in mainline kernel instead.
Indeed. So such extension would receive a bit a public scrutiny.
Powered by blists - more mailing lists