Skip to content
This repository has been archived by the owner on Jul 6, 2019. It is now read-only.

Conventions for reference mutability of hardware resources #377

Open
gsnoff opened this issue Jun 11, 2016 · 3 comments
Open

Conventions for reference mutability of hardware resources #377

gsnoff opened this issue Jun 11, 2016 · 3 comments

Comments

@gsnoff
Copy link

gsnoff commented Jun 11, 2016

Currently, all methods in traits describing hardware classes (such as GPIO pins and SPI bus interfaces) use non-mutable &self pointers. This might cause problems with two or more consumers meddling with hardware state at the same time and getting into race conditions, for example, which are going to be very hard to diagnose at some point.

I have a suggestion to make the methods require &mut self pointers, except for those which are generally thread-safe and, more importantly, guaranteed to not change hardware state. What this means, is that operations such as send, receive (since it shifts buffer registers), write pin state, change pinmux configuration etc. should require mutability of the corresponding hardware resource. However peek (get buffer contents without shifting it), read pin state, get current time and similar operations may be made to work with non-mutable resources.

Also, in case of devices depending on underlying lower-level resources (for example, most real-time clocks and on-board sensors using buses such as I2C or SPI), the device driver owning mutable references to those resources may expose methods which don't require mutability - for operations which don't change the overall hardware state except for lower level bus registers etc., abstracted away by the driver. The driver, however, should ensure thread safety of those methods via locking mechanisms, atomicity guarantees and whatnot.

@farcaller
Copy link
Member

That sounds like an overall good idea, but I'm not sure that the hardware is always used in exclusive mode, e.g. it's a valid, and often used scenario to have several devices on SPI bus, so you can't hold the &mut on it. This noted, it should be a scheduled exclusive access, so maybe it's actually a job for a mutex-like thing.

@gsnoff
Copy link
Author

gsnoff commented Jun 17, 2016

In case of SPI, I think it'd be reasonable to make the drivers provide separate chipselect resources which would abstract away their mutual exclusiveness with mutexing or spinlocking when needed.

@farcaller
Copy link
Member

farcaller commented Jun 17, 2016 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants