Discussion on capability based access to I2C

[jschilli]

disclaimer - I haven't followed the standards process for prior WASI initiatives so my question may be off base.

With other wasi standards (filesystem/http/cli) the defined interfaces don't appear to bow to the capability backed implementation (preopens, env, args, etc) and so it seems (appropriately) that I2c follows that model.

having said that should the reference implementations address this? Should the proposal verbiage address this?

Again to the issues raised in #2 it's complicated across the set of environments in which I2C is supported. I know that we intend to have I2C an opt in/gated capability.

Thoughts?

[sunfishcode]

I've been thinking through this question several times and trying to figure out how to answer it :-). I wonder if it would make sense to just add a documentation note saying something like:

Q: Why are there no constructors for the i2c interface? How does one obtain an i2c handle?

A: I2c resources will be constructed in many different ways on different devices, so worlds that include the i2c interface should also include a way to obtain i2c handles. Typically this will either be by having i2c handles passed into exported functions as parameters, or by having i2c handles returned from imported functions.

Does that answer your question?

[jschilli]

@sunfishcode I suppose this hits questions #2 and #3 - you made the point earlier that the realm of i2c|gpio|spi aren't bound to legacy constraints or expectations like std I/o etc - so while it answers the questions and I think it would be an improvement to the doc to add it I'm encouraging all of us to be thinking about having a defensible security posture as we begin to open up new facets of the wasi model.

would you like a PR to the docs?

and thank you again for taking the time to think through this.

[sunfishcode]

Yeah, I think a PR would be good.