Add support for host features. - #91
Conversation
The `proxy_get_host_features` hostcall can be used by the SDKs to determine which features are supported by the host environment. Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
|
As mentioned in the meeting, this is still missing text about hosts generating |
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
4555560 to
1042a69
Compare
leonm1
left a comment
There was a problem hiding this comment.
LGTM for merging.
I propose we merge this as-is and handle guest required features in a different PR, so we can build on HOST_FEATURES.md in other PRs.
…ures Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
| - `UNIMPLEMENTED` = `12` | ||
| - `UNKNOWN_RESOURCE_ID` = `13` | ||
| - `CREATED` = `14` | ||
| - `NOT_SUPPORTED` = `15` |
There was a problem hiding this comment.
There was a problem hiding this comment.
Switching it to NOT_SUPPORTED seems desirable for uniformity, I guess the concern is about backwards compatibility? It would only be a change to the return code in the failure case, so I think that change is unlikely to be disruptive.
Is there a meaningful distinction between UNIMPLEMENTED and NOT_SUPPORTED, though? If it's just that NOT_SUPPORTED is more general, how about renaming value 12 from UNIMPLEMENTED to NOT_SUPPORTED (and maybe retaining an enum alias)?
The
proxy_get_host_featureshostcall can be used by the SDKs todetermine which features are supported by the host environment.