On Fri, February 17, 2012 03:22, H. Peter Anvin wrote: > On 02/16/2012 06:16 PM, Andrew Lutomirski wrote: >> >> Is there really no syscall that cares about endianness? Perhaps when 64-bit syscall args are passed via two 32-bit registers. But that is no argument to make all argument accesses endianness aware. >> Even if it ends up working, forcing syscall arguments to have a >> particular endianness seems like a bad decision, especially if anyone >> ever wants to make a 64-bit BPF implementation. (Or if any >> architecture adds 128-bit syscall arguments to a future syscall >> namespace or whatever it's called. x86-64 has 128-bit xmm >> registers...) >> > > Not to mention that the reshuffling code will add totally unnecessary > cost to the normal operation. There is no such extra cost. > Either way, Indan has it backwards ... it > *is* one field, the fact that two operations is needed to access it is a > function of the underlying byte code, and even if the byte code can't > support it, a JIT could merge adjacent operations if 64-bit operations > are possible -- or we could (and arguably should) add 64-bit opcodes in > the future for efficiency. It is a virtual data structure with as sole purpose to provide syscall info to the byte code. The actual data structure as such never exists in memory. So giving something that is hard to digest is silly. A JIT won't be able to merge accesses because it also has to merge other instructions and recognize when 64-bit operations are done with 32-bit instructions. I think that will be too hard for a JIT. The only good reason to use 64 bit fields is if 64-bit support will be added to BPF in the future. If not, then it's just unnecessary pain for no good reason. An alternative to struct seccomp_data would be to add special instructions that load the desired info to 'A'. E.g. BPF_S_ANC_SYSCALL_ARG with 'k' selecting which arg. But that's probably harder to fit into the current filter code. Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
