On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > 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? As long as it accepts relative paths, I think it will always work. Worst case, a user has to cd. No need for hardcoding the bpf mount point at compile time. I have the matching iptables patch for pinned objects, btw. Not for elf objects, which requires linking to libelf and parsing the object, which is more work (and perhaps best punted on by expanding libbpf in bcc to include this functionality. it already exists under samples/bpf and iproute2). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
