Hi @areusch ,
Thanks for taking time to put this all up. Overall it makes sense to me. > > (TODO, but not as a result of this RFC) Group the non-host modules by > target_type (except that ext_dev target_types should be expanded to a unique > key per BYOC). Save each generated module into a file underneath > `./codegen/<target_type>`. Yes, currently for uTVM BYOC codegen, we are currently working on is producing a DSOExportable (we might need to re-think of this terminology as well :) ) module of type "c". One of the things missing is a way to say the codegen name in the runtime.Module without overloading type_key. So this is known as "compiler" attribute in the external function in the world of Relay before calling the BYOC compilation that converts Relay IRModule --> runtime.Module. However, a draw-back of this approach is Project-API that consume this will need to be aware of the folder structure based on composite target. Do we need that complexity ? If not, I would suggest we use a single flat hierarchy to store the sources ? if we need more clarity, we can be explicit with the naming. E.g. : host_module.c metadata.c accel_0.c. WDYT? --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-tvm-model-library-format/9121/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/f22ce5df319b887eeb469e243c2a791ec3ebb76485da4b81862df11e5b48707d).
