Mousius commented on PR #13707: URL: https://github.com/apache/tvm/pull/13707#issuecomment-1424336022
> Thanks @Mousius i outlined the goal, and possible approaches. Technically they are all feasible and actionable. > > By listing these suggestions, of course that is my best intent of collaboration since we also need to reconcile the needs and overall architectural decisions in the project as a whole. Looking at your reply, you probably might could use W2 (so the changes are properly fixed together as a sequeqnce plus any followup fixes that you might prefer). > > Please feel free to also suggest other possible actions that can address G0 I have put forward suggestions, you have not included them: * This is a non-issue, both Rust and C are general-purpose languages with embedded specific engineers, there is no need to discriminate. * If this is an issue, I have offered to fix this more broadly and fix both interface APIs which will likely result in a much broader discussion on how to make this clearer in future. I was more than happy to work on something to fix the Embedded APIs, as many C engineers work in system environments which aren't embedded; this is a broken window in our overall architecture that doesn't seem to be recognised and thus there appears to be no value in such an RFC. > For example use the term `interface_embedded_rust` would leave room and allow developers to not have confusion given there can be other interfaces of rust, as per discussion of rationales in this RFC [apache/tvm-rfcs#96](https://github.com/apache/tvm-rfcs/pull/96) Yip, I was hopeful that given responses elsewhere, there would be some interest in moving this forwards with an open mindset and encouragement to follow up with a broader discussion on the proper fix rather than being blocked on a file name. And we have fair precedent for moving forwards without an RFC so thought I would test the water here. > W1: We can try to open a thread in the community to get a broad sense of what everyone's inputs are (wrt to the overall naming and scoping), which i would also be interested in hearing from. > W2: If we feel a sequence of changes is needed that goes beyond a single PR to bring the set of things into a ready state, we can also try to open a branch, in which case the change is also reasonably isolate, and we are more than welcome to commit the change to branch, continue followup developments, and we can re-access when we think things are at a ready state to address G0. * W1 is just another place for the same cyclic discussion demonstrated both here and in the RFC * W2 moves the issue to the future, which is a shame for such a small change which could benefit real users - given the discussions here I don't see this ever landing in `main` unless I fulfil W0. > W0: Do the renaming directly, since I think it won't affect the functionality of the proposed feature and related users, but would also benefit other users/developers who use rust API in different ways. Feel free to bring followup changes to also align the c if necessary, although given the context of C(more in embedded i do not feel that is a requirement) Overall, I do not want to introduce these inconsistencies in the codebase nor do I wish to endorse the view that both C and Rust are not general purpose languages, yet I feel forced to W0 in order to progress. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
