lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 8 Sep 2014 08:37:23 +0200
From:	Ingo Molnar <>
To:	David Miller <>
Subject: Re: [PATCH v10 net-next 2/2] net: filter: split filter.h and expose
 eBPF to user space

* David Miller <> wrote:

> From: Ingo Molnar <>
> Date: Mon, 8 Sep 2014 07:23:29 +0200
> > 
> > * Alexei Starovoitov <> wrote:
> > 
> >> > 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.
> >> 
> >> You're not correct here. I'm not saying 'I promise it will 
> >> be submitted'. There _were_ already submitted. [...]
> > 
> > And this split-up smaller submissions was requested by David 
> > Miller, the networking maintainer, so if Pablo wants another 
> > submission format, he needs to take it up with David - we 
> > can't do both at once obviously.
> I think that just because I asked the submission size to be 
> smaller, it does not mean that you can submit things before you 
> provide the initial user as well.
> And how to work that out and keep the submission size 
> reasonable is the submitter's problem, not mine.

That's a pretty harsh requirement but might be doable 
technically: Alexei, please submit a series that is large enough 
to provide self-sufficient functionality as per Pablo's request,
but is also small and minimal, as per David's request.

If that fails then another route would be to decouple from 
networking initially and create something new and stand-alone in 
kernel/ebpf/ (or any other name really), with tracing and perf 
usecases, with networking integration and code deduplication to 
be done at the end, when there can be no legitimate argument 
about its utility.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists