From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netfilter-devel@vger.kernel.org,
Network Development <netdev@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Willem de Bruijn <willemb@google.com>,
Florian Westphal <fw@strlen.de>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf
Date: Tue, 6 Dec 2016 00:22:14 +0100 [thread overview]
Message-ID: <20161205232214.GA15825@salvia> (raw)
In-Reply-To: <CAF=yD-Jk4W+zU=tdixWe3LPGcFp-sANxXLLoQTRvrkN_3=a9uw@mail.gmail.com>
On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote:
[...]
> Eric also suggests a private variable to avoid being subject to
> changes to PATH_MAX. Then we can indeed also choose an arbitrary lower
> length than current PATH_MAX.
Good.
> FWIW, there is a workaround for users with deeply nested paths: the
> path passed does not have to be absolute. It is literally what is
> passed on the command line to iptables right now, including relative
> addresses.
If iptables userspace always expects to have the bpf file repository
in some given location (suggesting to have a directory that we specify
at ./configure time, similar to what we do with connlabel.conf), then
I think we can rely on relative paths. Would this be flexible enough
for your usecase?
next prev parent reply other threads:[~2016-12-05 23:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 20:28 [PATCH nf-next] netfilter: xt_bpf: support ebpf Willem de Bruijn
2016-12-05 21:06 ` Eric Dumazet
2016-12-05 21:30 ` Florian Westphal
2016-12-05 22:34 ` Pablo Neira Ayuso
2016-12-05 22:40 ` Florian Westphal
2016-12-05 22:59 ` Eric Dumazet
2016-12-05 23:05 ` Pablo Neira Ayuso
2016-12-05 23:00 ` Pablo Neira Ayuso
2016-12-05 23:06 ` Willem de Bruijn
2016-12-05 23:22 ` Pablo Neira Ayuso [this message]
2016-12-05 23:29 ` Willem de Bruijn
2016-12-05 23:51 ` Willem de Bruijn
2016-12-06 0:20 ` Florian Westphal
2016-12-06 22:44 ` Willem de Bruijn
2016-12-05 22:55 ` Daniel Borkmann
2016-12-05 23:01 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161205232214.GA15825@salvia \
--to=pablo@netfilter.org \
--cc=daniel@iogearbox.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.