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
sock_filter_int
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 simpl
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 class
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 capt
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 a
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 abo
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 future
* 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 t
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 kn
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 seccomp_check_fi
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 spl
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, probabl
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 ent
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 b
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 pa
20 matches
Mail list logo