On Sat, Feb 04, 2017 at 07:22:03PM -0800, Andy Lutomirski wrote: > On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote: > >> > So use-case would be that someone wants to attach the very same > >> > prog via tc to various netdevs sitting in different netns, and > >> > that prog looks up a map, controlled by initns, with skb->netns_inum > >> > as key and the resulting value could contain allowed feature bits > >> > for that specific netns prog the skbs goes through? That would be > >> > a feature, not "concern", no? At the same time, it's up to the > >> > user or mgmt app what gets loaded so f.e. it might just as well > >> > tailor/optimize the progs individually for the devs sitting in > >> > netns-es to avoid such map lookup. > >> > >> Agreed. I don't see why you would install the exact same program on > >> two sockets in different netnses if the program contains, say, an > >> ifindex. Why not just install a variant with the right ifindex into > >> each socket? > > > > In other cases people prefer to have one program compiled once > > and thoroughly tested offline, since some folks are worried > > that on-the-fly compilation may cause generated code to > > be rejected by the verifier. > > I would be rather surprised if someone wrote a program that did had an > expression like (ifindex == 17), tested it offline, and refused to > update the 17 based on the actual ifindex in use.
All programs have bugs. What bpf subsytem is trying to do is to be flexible and satisfy as many use cases as possible. Boxing users into "one way to do things" isn't a successful strategy in my opinion. perl vs python, if you like :) bpf is perl like. We don't enforce spaces vs tabs :)
