New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/exp/io: distinguish transport layer config from protocol required config #15803
Comments
+1 for passing protocol level argument (i.e: addresses), independently from backend specific args ( |
SGTM.
|
Having to pass the address all the time is confusing for new users and since it's static and related to the i2c device you are targeting. The part I don't quite understand tho is how/why the proxy would know about the address to implement the
Shouldn't the
|
This is exactly why we are putting the addr back to Open, so the devfs driver won't need you to pass it. Higher level packages, such as the grovelcd package, can hardcode it and encapsulate from the user.
Am I misunderstanding anything? |
No, it was me being confused. It looks great |
CL https://golang.org/cl/24215 mentions this issue. |
Currently, in order to keep the driver implementations extendible enough, driver.Opener interfaces requires no arguments. But it is creating barriers in the reusability of certain configuration fields.
I implemented the following high-level Grove LCD package and running it against i2c.Devfs and a custom driver that talks through a web service.
What is not nice is that grovelcd package cannot embed the I2C address required by the device at the device library level since Addr needs to be injected by the transport layer, i2c.Devfs.
We should distinguish such arguments from the driver implementation configurations to allow libraries to encapsulate the protocol details from the users.
The new i2c.Driver should look like:
And the user should only care about opening the right bus, address will be embedded in grovelcd package.
Thoughts?
/cc @minux @proppy
The text was updated successfully, but these errors were encountered: