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 that, no? Sure it doesn't fit into the concept, but I think at the time BPF extensions were introduced, it was probably seen as the best trade-off available to access useful skb fields while still trying to minimize exposure to uapi as much as possible.
This split is not trying to make classic easier to hack. With eBPF underneath classic, it got a lot easier to add extensions to classic, but we shouldn't be doing it. Classic BPF is not generic and cannot become one. It's eBPF's job. The split is mainly helping to clearly see the boundary of eBPF core vs its socket use case. It doesn't change or add any API.
So what's the plan with everything in arch/*/net/, tools/net/ and in Documentation/networking/filter.txt, plus MAINTAINERS file, that the current patch doesn't address? We want changes to go via net...@vger.kernel.org as they always did, since [ although other use cases pop up ] the main user, as I said, is simply still packet filtering in various networking subsystems, no?
This in-kernel API cleanup was done in commit 5fe821a9dee2 You even acked it back then :)
I agreed with that change, otherwise I wouldn't have acked it, of course. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
