On Fri, Dec 20, 2013 at 1:13 PM, Alexander Nasonov <al...@yandex.ru> wrote: > Sorry for top-posting. I'm replying from my phone. > > I've not looked at linux bpf before. I remember taking a quick look at > bpf_jit_compile function but I didn't like emitting binary machine code with > macro commands. > > I spent few minutes today looking at linux code and I noticed few interesting > things: > > - They use negative offsets to access auxiliary data. So, there is a clear > distinction between local memory store and external data. I don't think it's > a new addition, though. > - They have a big enum of commands. Many of them translate to bpf commands > but there are also special commands like load protocol number into A. There > is a decoder from bpf but I have no clue how it works. > - Those commands are adapted to work with skbuf data.
I have used some of the "non traditional" uses of bpf in Linux, in particularly the syscall filtering code, which is designed to be a bit like the packet filtering code. But I don't think it is a great model, and I think the jit compiler is rather different, as it compiles to asm. And the current route they are going seems to be validation rather than in kernel jitting, see https://lwn.net/Articles/575531/ Justin > Alex > > > 20.12.13, 04:16, "David Laight" <da...@l8s.co.uk>": >> >> On Fri, Dec 20, 2013 at 01:28:12AM +0200, Mindaugas Rasiukevicius wrote: >> > Alexander Nasonov <al...@yandex.ru> wrote: >> > > >> > > Well, if it wasn't needed for many year in bpf, why do we need it now? >> > > ;-) >> > > >> > >> > Because it was decided to use BPF byte-code for more applications and that >> > meant there is a need for improvements. It is called evolution. :) >> >> Has anyone here looked closely at the changes linux is making to bpf? >> >> David >> >> -- >> David Laight: da...@l8s.co.uk > > > -- > Alex