On 8/13/15 2:35 PM, pi3orama wrote:
I was thinking about whether to add a "type" field there, so we will have an explicit mov const instruction before the call instruction, which can act as a mark. Also, if we generate the type code automatically, a type field in this API can make things easier since we don't need wrap the user structure in BPF stack. However, the LLVM side is not ready yet, so we haven't post the new version.
I think the helper was clean enough. Any type info probably needs to be done as a side channel and not part of the helper anyway. But, ok, let's figure out the type stuff first. Also I don't think you can rely on extra insn in front of a call insn. Compiler can freely insert other insns there. You don't want to introduce data flow analysis in elf parser. -- 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/