* Alexei Starovoitov wrote:
> It's possible to teach it for multi-level, but then analyzer will
> become too large and won't be suitable for kernel.
Btw., even if we want to start simple with most things, the above
statement is not actually true in the broad sense: the constraint for
the ker
On Tue, Dec 3, 2013 at 12:41 PM, Frank Ch. Eigler wrote:
>
> Alexei Starovoitov writes:
>
>> [...]
>>> Having EBPF code manipulating pointers - or kernel memory - directly
>>> seems like a nonstarter. However, per your subsequent paragraph it
>>> sounds like pointers are a special type at which
Alexei Starovoitov writes:
> [...]
>> Having EBPF code manipulating pointers - or kernel memory - directly
>> seems like a nonstarter. However, per your subsequent paragraph it
>> sounds like pointers are a special type at which point it shouldn't
>> matter at the EBPF level how many bytes it t
On Tue, Dec 3, 2013 at 9:01 AM, H. Peter Anvin wrote:
> On 12/02/2013 08:28 PM, Alexei Starovoitov wrote:
>> +
>> +All BPF registers are 64-bit without subregs, which makes JITed x86 code
>> +less optimal, but matches sparc/mips architectures.
>> +Adding 32-bit subregs was considered, since JIT ca
On 12/02/2013 08:28 PM, Alexei Starovoitov wrote:
> +
> +All BPF registers are 64-bit without subregs, which makes JITed x86 code
> +less optimal, but matches sparc/mips architectures.
> +Adding 32-bit subregs was considered, since JIT can map them to x86 and
> aarch64
> +nicely, but read-modify-w
Signed-off-by: Alexei Starovoitov
---
Documentation/bpf_jit.txt | 204 +
1 file changed, 204 insertions(+)
create mode 100644 Documentation/bpf_jit.txt
diff --git a/Documentation/bpf_jit.txt b/Documentation/bpf_jit.txt
new file mode 100644
index
6 matches
Mail list logo
