On Tue, Aug 26, 2014 at 9:35 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: > On Tue, Aug 26, 2014 at 8:56 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Aug 26, 2014 7:29 PM, "Alexei Starovoitov" <ast@xxxxxxxxxxxx> wrote: >>> >>> Hi Ingo, David, >>> >>> posting whole thing again as RFC to get feedback on syscall only. >>> If syscall bpf(int cmd, union bpf_attr *attr, unsigned int size) is ok, >>> I'll split them into small chunks as requested and will repost without RFC. >> >> IMO it's much easier to review a syscall if we just look at a >> specification of what it does. The code is, in some sense, secondary. > > 'specification of what it does'... hmm, you mean beyond what's > there in commit logs and in Documentation/networking/filter.txt ? > Aren't samples at the end give an idea on 'what it does'? > I'm happy to add 'specification', I just don't understand yet what > it suppose to talk about beyond what's already written. > I understand that the patches are missing explanation on 'why' > the syscall is being added, but I don't think it's what you're asking... I mean a hopefully short document that defines what the syscall does. It should be precise enough that one could, in principle, implement the syscall just by reading the document and that one could use the syscall just by reading the document. Given that there's a whole instruction set to go with it, it may end up being moderately complicated or saying things like "see this other thing for a description of the instruction set" and "there are some extensible sets of functions you can call with it". --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
