Detect whether the host has a certain ability

[oovm]

I most recently saw this project https://github.com/bytecodealliance/WASI-Virt

This is very useful, but I now have a question about the interface provided by the host.

Does the host must to implement all interfaces specified in the final phase of wasi?

Considering that the performance of some embedded devices is very weak, it is unlikely to implement overly complex interfaces, such as wasi-nn.

Should an interface be provided to query whether the host actually implements a certain interface? ​ If not all interface must be implemented, I hope to be able to query the following status of the interface:

enum {
    // It is forbidden to call this interface (trap immediately)
    // for example, not implemented
    deny,
    // Allow calling this interface
    allow,
    // This interface does not actually exist, but it can be called without trap, and the behavior does not comply with the operation.
    // for example, random numbers always return 0(default value).
    // stdout will not actually produce any message. 
    // http requests will not actually be issued, etc.
    virtual, 
    // The interface exists, but there is no calling permission (trap immediately)
    // for example, if the user has not been granted permission to view the file, you should ask the user to check the pop-up window first.
    insufficient-permissions
}

[lukewagner]

Good question and agreed that we can't be expecting every host to implement every WASI interface. Indeed, one of the earliest-stated goals of WASI was to be "modular", in the sense that WASI was composed of a set of interfaces and any particular host could implement any particular subset of these interfaces. To this end, the point of WIT having explicit worlds is to explicitly define and name subsets of WASI (and other) interfaces. Thus, wasi:http/proxy contains a distinct (but intersecting) set of imports from wasi:cli/command and so host implementing wasi:http/proxy are not forced to implement, e.g., wasi:filesystem/types (which makes sense: many HTTP proxies have no meaningful filesystem to expose).

Over time, WASI will define more worlds capturing different categories of hosts. Some worlds will be pretty slim and consequently run on a lot of different hosts (this is a goal for wasi:http/proxy) whereas other worlds will have a bunch of stuff and thus run on a more focused set of hosts (e.g., see wasi:cloud-core/service). I think folks are recently working on one or more wasi:embedded worlds, and they'll obviously be pretty careful in what they include.

A relevant technical detail is that the name of the world targeted by a component doesn't physically appear in the component -- only the names of the individual imported and exported interfaces. Thus, worlds are effectively "structurally-typed" with the question of whether a particular component will run on a particular host determined by subtyping.

Lastly, from your suggested enum, you may also be thinking of a component that wants to import some functionality if it's present, but can gracefully fallback if it's not. To support this kind of use case, we've discussed adding an optional type-constructor so that a component can optionally import some interface, which the Canonical ABI would allow you to dynamically test and handle accordingly. That's not proposed yet, but it seems like just a matter of time until we add it.

Hope that helps!

[oovm]

Yes, that's a good idea.

The fallback scheme reminds me of the shader language. Faced with the huge difference in gpu capabilities, shaders have found a widely used scheme.

If we can statically decide which implementation to fall back to at the component level, it will be much less expensive than judging based on enum every time it is called inside the language.