This is great @areusch! I appreciate the ability to re-introduce `c_backend_api.h` to leverage existing abstractions without having to necessarily use `c_packed_func.h`. It'd be great if we only required the single backend header file, I think the only thing that prevents is having to copy `function_attributes.h` across as well - I'd suggest all of the backend definition, including attributes, could live in the single `c_backend_api.h`?
Extending that a bit, if we only need to take `c_backend_api.h` into a project as a header, could we not raise these headers out of the runtime folder? Potentially `include/tvm/c_backend_api.h` or even `include/tvm_backend_api.h`? My assumption here is that the backend would always be written in something with a stable C ABI. This could potentially be true of `c_packed_func.h`/`tvm_packed_func.h` as well, leaving only the runtime-specific headers in the runtime folder? [quote="areusch, post:1, topic:10380"] Rename `TVMBackendPackedCFunc`. `PackedCFunc` merges two names together into a confusing amalgamation. * R1. `TVMCPackedFunc` (conflicts with `tvmc` the command-line tool…) * R2. `CTVMPackedFunc` * R3. `TVMBackendCPackedFunc` (readable but not `Backend`-only) [/quote] I'd be interested in considering just `TVMPackedFunc`? Is there a reason to mark it explicitly as a C function? --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-api-change-formalizing-c-backend-api/10380/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/515043671afadae3f2a0e502cfdd58042100e9cac0602ee35bdadf0494e3431d).
