alexcrichton commented on issue #6821:
One part of this is that it defines a hierarchy of types and then provides conversion of WIT and WITX-generated types into this hierarchy of types. That's reasonable for this crate since the set of types is quite small, but for something like
wasi-common
I'm not sure if that would work well (or larger proposals). In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated? That way there'd only be one conversion necessary which is WITX-to-WIT.Also one thing to consider is that this has
impl WasiNnTrait for WasiNnCtx
which means that it's not going to be easily usable from embedders. Currently withbindgen!
we're using something that looks likeimpl<T> WasiNnTrait for T where T: WasiNnView
so that way ifWasiNnCtx
is embedded in a store somewhere theWasiNnView
defines how to access it.Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?
abrown commented on issue #6821:
In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated
Yeah, I would prefer that. Is it fine if
wasmtime-wasi-nn
enables thecomponent-model
feature, though, forcing every user of this (e.g., the CLI) to do so too?
impl<T> WasiNnTrait for T where T: WasiNnView
I saw this over in
wasi
orwasi-common
and didn't really "get" it. Let me look into it a bit more.Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?
They are duplicated in essence but not all the details are the same; e.g., anywhere we need a slice in
witx.rs
we do the WiggleGuestSlice
dance. I'll look into this a bit more...
abrown commented on issue #6821:
@alexcrichton: one more thought about your comments is that perhaps some of these improvements could be done as a separate PR. There is clearly more work that needs to be done here (e.g., replace all these temporary WIT files with their upstream versions, implement named models, etc.) so perhaps some of the refactorings you suggest could fit into some of those PRs.
Last updated: Dec 23 2024 at 13:07 UTC