* 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
On Sun, Sep 7, 2014 at 10:28 PM, 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
>>> >
On Sun, Sep 7, 2014 at 10:28 PM, David Miller da...@davemloft.net wrote:
From: Ingo Molnar mi...@kernel.org
Date: Mon, 8 Sep 2014 07:23:29 +0200
* Alexei Starovoitov a...@plumgrid.com wrote:
I don't think the speed up of the llvm submission is a good
argument, this sounds to me similar
* David Miller da...@davemloft.net wrote:
From: Ingo Molnar mi...@kernel.org
Date: Mon, 8 Sep 2014 07:23:29 +0200
* Alexei Starovoitov a...@plumgrid.com wrote:
I don't think the speed up of the llvm submission is a
good argument, this sounds to me similar to the please
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
>> >
* 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
On Sun, Sep 7, 2014 at 11:07 AM, Pablo Neira Ayuso wrote:
>
> 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,
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 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
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 pa...@netfilter.org 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
On Sun, Sep 7, 2014 at 11:07 AM, Pablo Neira Ayuso pa...@netfilter.org wrote:
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
* Alexei Starovoitov a...@plumgrid.com 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
From: Ingo Molnar mi...@kernel.org
Date: Mon, 8 Sep 2014 07:23:29 +0200
* Alexei Starovoitov a...@plumgrid.com 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
On Sat, Sep 6, 2014 at 7:10 AM, Pablo Neira Ayuso 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
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
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,
On Sat, Sep 6, 2014 at 7:10 AM, Pablo Neira Ayuso pa...@netfilter.org 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
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
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
18 matches
Mail list logo
