On 06/23/2014 11:57 PM, Alexei Starovoitov wrote:
On Fri, Jun 20, 2014 at 9:44 AM, Chema Gonzalez wrote:
...
- nop: I'd like to have a nop. Do I know why? Nope.
nope. Let's not add unnecessary instructions.
A valid nop is a useful instruction: padding, filling up arrays of
On 06/23/2014 11:57 PM, Alexei Starovoitov wrote:
On Fri, Jun 20, 2014 at 9:44 AM, Chema Gonzalez ch...@google.com wrote:
...
- nop: I'd like to have a nop. Do I know why? Nope.
nope. Let's not add unnecessary instructions.
A valid nop is a useful instruction: padding, filling up arrays
On Fri, Jun 20, 2014 at 9:44 AM, Chema Gonzalez wrote:
>>
>> Model eBPF based on MIPS ISA? Ouch.
>> That would be one ugly ISA that is not JITable on x64.
>
> Definitely I wasn't making my point clear: IMO if we're redesigning
> the BPF ISA, we should get a clean one (clean=something that is
From: Chema Gonzalez
...
> 4.5. BPF_ST|BPF_MEM
> Operation: *(size *) (dst_reg + off16) = imm32
>
> This insn encodes 2 immediate values (the offset and the imm32 value)
> in the insn, and actually forces the sock_filter_int 64-bit struct to
> have both a 16-bit offset field and a 32-bit
On Fri, Jun 20, 2014 at 9:44 AM, Chema Gonzalez ch...@google.com wrote:
Model eBPF based on MIPS ISA? Ouch.
That would be one ugly ISA that is not JITable on x64.
Definitely I wasn't making my point clear: IMO if we're redesigning
the BPF ISA, we should get a clean one (clean=something that
From: Chema Gonzalez
...
4.5. BPF_ST|BPF_MEM
Operation: *(size *) (dst_reg + off16) = imm32
This insn encodes 2 immediate values (the offset and the imm32 value)
in the insn, and actually forces the sock_filter_int 64-bit struct to
have both a 16-bit offset field and a 32-bit immediate
[Sorry for the delay in the answer. Been mired somewhere else.]
On Tue, Jun 3, 2014 at 5:38 PM, Alexei Starovoitov wrote:
> On Tue, Jun 3, 2014 at 2:40 PM, Chema Gonzalez wrote:
>> First of all, and just to join the crowd, kernel/bpf/ FTW.
>>
>> Now, I have some suggestions about eBPF. IMO
[Sorry for the delay in the answer. Been mired somewhere else.]
On Tue, Jun 3, 2014 at 5:38 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Jun 3, 2014 at 2:40 PM, Chema Gonzalez ch...@google.com wrote:
First of all, and just to join the crowd, kernel/bpf/ FTW.
Now, I have some
On Tue, Jun 3, 2014 at 2:40 PM, Chema Gonzalez wrote:
> First of all, and just to join the crowd, kernel/bpf/ FTW.
>
> Now, I have some suggestions about eBPF. IMO classic BPF is an ISA
> oriented to filter (meaning returning a single integer that states how
> many bytes of the packet must be
First of all, and just to join the crowd, kernel/bpf/ FTW.
Now, I have some suggestions about eBPF. IMO classic BPF is an ISA
oriented to filter (meaning returning a single integer that states how
many bytes of the packet must be captured) packets (e.g. consider the
6 load modes, where 3 provide
On Tue, Jun 3, 2014 at 1:35 PM, Daniel Borkmann wrote:
> On 06/03/2014 05:44 PM, Alexei Starovoitov wrote:
> ...
>>
>> All of your points are valid. They are right questions to ask. I just
>>
>> don't see why you're still arguing about first step of filter.c split,
>> whereas your concerns are
On 06/03/2014 05:44 PM, Alexei Starovoitov wrote:
...
All of your points are valid. They are right questions to ask. I just
don't see why you're still arguing about first step of filter.c split,
whereas your concerns are about steps 2, 3, 4.
Fair enough, lets keep them in mind though for
* Alexei Starovoitov wrote:
> On Mon, Jun 2, 2014 at 7:16 AM, Arnaldo Carvalho de Melo
> wrote:
> > Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
> >> On Mon, 2 Jun 2014 08:15:45 -0500
> >> Jonathan Corbet wrote:
> >
> >> > On Mon, 2 Jun 2014 00:01:44 -0700
> >> > Alexei
On Tue, Jun 3, 2014 at 1:56 AM, Daniel Borkmann wrote:
> On 06/02/2014 09:02 PM, Alexei Starovoitov wrote:
> ...
>>
>> Classic has all sorts of hard coded assumptions. The whole
>>
>> concept of 'load from magic constant' to mean different things
>> is flawed. We all got used to it and now think
On 06/02/2014 09:02 PM, Alexei Starovoitov wrote:
...
Classic has all sorts of hard coded assumptions. The whole
concept of 'load from magic constant' to mean different things
is flawed. We all got used to it and now think that it's normal
for "ld_abs -4056" to mean "a ^= x"
I think everyone
On 06/02/2014 09:02 PM, Alexei Starovoitov wrote:
...
Classic has all sorts of hard coded assumptions. The whole
concept of 'load from magic constant' to mean different things
is flawed. We all got used to it and now think that it's normal
for ld_abs -4056 to mean a ^= x
I think everyone knows
On Tue, Jun 3, 2014 at 1:56 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 06/02/2014 09:02 PM, Alexei Starovoitov wrote:
...
Classic has all sorts of hard coded assumptions. The whole
concept of 'load from magic constant' to mean different things
is flawed. We all got used to it and now
* Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Jun 2, 2014 at 7:16 AM, Arnaldo Carvalho de Melo
a...@kernel.org wrote:
Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
On Mon, 2 Jun 2014 08:15:45 -0500
Jonathan Corbet cor...@lwn.net wrote:
On Mon, 2 Jun
On 06/03/2014 05:44 PM, Alexei Starovoitov wrote:
...
All of your points are valid. They are right questions to ask. I just
don't see why you're still arguing about first step of filter.c split,
whereas your concerns are about steps 2, 3, 4.
Fair enough, lets keep them in mind though for
On Tue, Jun 3, 2014 at 1:35 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 06/03/2014 05:44 PM, Alexei Starovoitov wrote:
...
All of your points are valid. They are right questions to ask. I just
don't see why you're still arguing about first step of filter.c split,
whereas your concerns
First of all, and just to join the crowd, kernel/bpf/ FTW.
Now, I have some suggestions about eBPF. IMO classic BPF is an ISA
oriented to filter (meaning returning a single integer that states how
many bytes of the packet must be captured) packets (e.g. consider the
6 load modes, where 3 provide
On Tue, Jun 3, 2014 at 2:40 PM, Chema Gonzalez ch...@google.com wrote:
First of all, and just to join the crowd, kernel/bpf/ FTW.
Now, I have some suggestions about eBPF. IMO classic BPF is an ISA
oriented to filter (meaning returning a single integer that states how
many bytes of the packet
On Mon, Jun 2, 2014 at 10:04 AM, Daniel Borkmann wrote:
> On 06/02/2014 05:41 PM, Alexei Starovoitov wrote:
> ...
>
>> Glad you brought up this point :)
>> 100% agree that current double verification done by seccomp is far from
>> being generic and quite hard to maintain, since any change done to
On 06/02/2014 05:41 PM, Alexei Starovoitov wrote:
...
Glad you brought up this point :)
100% agree that current double verification done by seccomp is far from
being generic and quite hard to maintain, since any change done to
classic BPF verifier needs to be thought through from
On Mon, Jun 2, 2014 at 1:57 AM, Daniel Borkmann wrote:
> On 06/02/2014 09:01 AM, Alexei Starovoitov wrote:
>>
>> This patch set splits BPF out of core networking into generic component
>>
>> patch #1 splits filter.c into two logical pieces: generic BPF core and
>> socket
>> filters. It only moves
On Mon, Jun 2, 2014 at 7:16 AM, Arnaldo Carvalho de Melo
wrote:
> Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
>> On Mon, 2 Jun 2014 08:15:45 -0500
>> Jonathan Corbet wrote:
>
>> > On Mon, 2 Jun 2014 00:01:44 -0700
>> > Alexei Starovoitov wrote:
>
>> > > This patch set
Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
> On Mon, 2 Jun 2014 08:15:45 -0500
> Jonathan Corbet wrote:
> > On Mon, 2 Jun 2014 00:01:44 -0700
> > Alexei Starovoitov wrote:
> > > This patch set splits BPF out of core networking into generic component
> > Quick,
On Mon, 2 Jun 2014 08:15:45 -0500
Jonathan Corbet wrote:
> On Mon, 2 Jun 2014 00:01:44 -0700
> Alexei Starovoitov wrote:
>
> > This patch set splits BPF out of core networking into generic component
>
> Quick, probably dumb question: if you're going to split it out, why not
> split it out
On Mon, 2 Jun 2014 00:01:44 -0700
Alexei Starovoitov wrote:
> This patch set splits BPF out of core networking into generic component
Quick, probably dumb question: if you're going to split it out, why not
split it out entirely, into kernel/ or (perhaps better) lib/? The
whole point seems to
On 06/02/2014 09:01 AM, Alexei Starovoitov wrote:
This patch set splits BPF out of core networking into generic component
patch #1 splits filter.c into two logical pieces: generic BPF core and socket
filters. It only moves functions around. No real changes.
patch #2 adds hidden CONFIG_BPF that
This patch set splits BPF out of core networking into generic component
patch #1 splits filter.c into two logical pieces: generic BPF core and socket
filters. It only moves functions around. No real changes.
patch #2 adds hidden CONFIG_BPF that seccomp/tracing can select
The main value of the
This patch set splits BPF out of core networking into generic component
patch #1 splits filter.c into two logical pieces: generic BPF core and socket
filters. It only moves functions around. No real changes.
patch #2 adds hidden CONFIG_BPF that seccomp/tracing can select
The main value of the
On 06/02/2014 09:01 AM, Alexei Starovoitov wrote:
This patch set splits BPF out of core networking into generic component
patch #1 splits filter.c into two logical pieces: generic BPF core and socket
filters. It only moves functions around. No real changes.
patch #2 adds hidden CONFIG_BPF that
On Mon, 2 Jun 2014 00:01:44 -0700
Alexei Starovoitov a...@plumgrid.com wrote:
This patch set splits BPF out of core networking into generic component
Quick, probably dumb question: if you're going to split it out, why not
split it out entirely, into kernel/ or (perhaps better) lib/? The
whole
On Mon, 2 Jun 2014 08:15:45 -0500
Jonathan Corbet cor...@lwn.net wrote:
On Mon, 2 Jun 2014 00:01:44 -0700
Alexei Starovoitov a...@plumgrid.com wrote:
This patch set splits BPF out of core networking into generic component
Quick, probably dumb question: if you're going to split it out,
Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
On Mon, 2 Jun 2014 08:15:45 -0500
Jonathan Corbet cor...@lwn.net wrote:
On Mon, 2 Jun 2014 00:01:44 -0700
Alexei Starovoitov a...@plumgrid.com wrote:
This patch set splits BPF out of core networking into generic
On Mon, Jun 2, 2014 at 7:16 AM, Arnaldo Carvalho de Melo
a...@kernel.org wrote:
Em Mon, Jun 02, 2014 at 09:24:56AM -0400, Steven Rostedt escreveu:
On Mon, 2 Jun 2014 08:15:45 -0500
Jonathan Corbet cor...@lwn.net wrote:
On Mon, 2 Jun 2014 00:01:44 -0700
Alexei Starovoitov a...@plumgrid.com
On Mon, Jun 2, 2014 at 1:57 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 06/02/2014 09:01 AM, Alexei Starovoitov wrote:
This patch set splits BPF out of core networking into generic component
patch #1 splits filter.c into two logical pieces: generic BPF core and
socket
filters. It only
On 06/02/2014 05:41 PM, Alexei Starovoitov wrote:
...
Glad you brought up this point :)
100% agree that current double verification done by seccomp is far from
being generic and quite hard to maintain, since any change done to
classic BPF verifier needs to be thought through from
On Mon, Jun 2, 2014 at 10:04 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 06/02/2014 05:41 PM, Alexei Starovoitov wrote:
...
Glad you brought up this point :)
100% agree that current double verification done by seccomp is far from
being generic and quite hard to maintain, since any
40 matches
Mail list logo
