Thread (15 messages) flat view 15 messages, 3 authors, 2015-03-16

Re: [PATCH v2 net-next 1/2] bpf: allow extended BPF programs access skb fields

From: Alexei Starovoitov <hidden>
Date: 2015-03-14 04:59:37
Also in: linux-api, lkml

On 3/13/15 7:27 PM, Alexei Starovoitov wrote:
On 3/13/15 7:16 PM, Daniel Borkmann wrote:
quoted
On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:
quoted
On 3/13/15 7:06 PM, Daniel Borkmann wrote:
quoted
On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...
quoted
Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/
Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].
nope. that defeats the purpose of bug_on.
Well, it doesn't. ;) It throws a build error thus the user is forced to
investigate that further.
according to this distorted logic all build_bug_on can be in one file
across the whole tree, since 'user is forced to investigate' ?!
also note that this case and twsk_build_assert are different.
twsk_build_assert has no other choice then to have one function
that covers logic in the whole file, whereas in this patch:
+               BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
+               *insn++ = BPF_LDX_MEM(BPF_W, dst_reg, src_reg,
+                                     offsetof(struct sk_buff, mark));

the build_bug_on protect the line directly below.
Separating them just doesn't make sense at all.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help