On Sat, Sep 06, 2014 at 09:04:23AM -0700, Alexei Starovoitov wrote: > On Sat, Sep 6, 2014 at 7:10 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Thu, Sep 04, 2014 at 10:17:18PM -0700, Alexei Starovoitov wrote: > >> allow user space to generate eBPF programs > >> > >> uapi/linux/bpf.h: eBPF instruction set definition > >> > >> linux/filter.h: the rest > >> > >> This patch only moves macro definitions, but practically it freezes existing > >> eBPF instruction set, though new instructions can still be added in the future. > >> > >> These eBPF definitions cannot go into uapi/linux/filter.h, since the names > >> may conflict with existing applications. > >> > >> Full eBPF ISA description is in Documentation/networking/filter.txt > > > > I think you need to have at least one single interface using this > > before you can expose it to userspace. So this should come in the > > small batch that introduces the first interface of your ebpf code in > > userspace. AFAIK, this has been the policy so far. > > That's what I've been doing over the last year. > My first eBPF patch was in Sep of 2013! > since then I've been only tweaking and massaging it. > Nothing fundamentally changed. > Last few month I've been posting these series with not only > first user, but with multiple. Many examples, test cases and so on. > The series became big and Dave asked to split them. > Please see the cover letter. These two patches is stage I. > More examples and use cases in stage II, stage III, stage IV, etc If the patches that provide the very first user interface don't get in time to this merge window round for whatever reason, we'll have the layout of this exposed to userspace in the next kernel version with no clients at all, that doesn't make sense to me. I don't think the speed up of the llvm submission is a good argument, this sounds to me similar to the "please apply this patch that reserves this new netlink family in include/linux/netlink.h, I promise this new subsystem will be submitted soon though. Meanwhile this will speed up submission of my userspace software to distributions for packaging" argument. I think you have to find the way to send a small batch with the very essencial stuff that, if merged mainstream, will provide just one new feature while leaving the repository in consistent state. Then, send follow up patches that enhance your thing and that add new clients of it. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
