Skip to content
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

Refactoring pull request #126

Merged
merged 6 commits into from
Aug 23, 2024
Merged

Refactoring pull request #126

merged 6 commits into from
Aug 23, 2024

Conversation

rneswold
Copy link
Contributor

This pull request contains some refactoring:

  • The API is v0.5.0, so all the Cargo.toml files need to refer to "0.5".
  • Made the device::Value::Str variant contain an Arc<str> instead of a String. This layout is much more efficient in that the string doesn't have to be copied for every client that reads a device that returns a string.
  • Wrapped the device tuples that hold the state of read-only and writable devices into two types: ReadOnlyDevice and ReadWriteDevice, respectively.

I bumped `drmem-api` to v0.5.0, but didn't update any of the packages
to it as well.
This will allow us to better partitions types when we enhance the
driver API.
The value associated with this variant is now an `Arc<str>`. Since
readings are sent through a broadcast channel, each value gets cloned
when delivered to a receiver. Cloning an `Arc` is much cheaper than
cloning the entire string.
Up to this point, when a device driver registered a read-only device,
it was given a `Sender<>` handle (to report new values returned by the
device) and the possible previous value of the device. When the driver
API went to the 3-phase lifecycle, the previous value was missplaced
(it couldn't be used during registration.)

With this commit, a new type is defined: `ReadOnlyDevice<T>`. It not
only lets the driver report new values using native types, but it also
hangs on to the previous value. This way the previous value can be
queried during the operational phase of the driver.
Create a new type which encapsulates the tuple that described the
state of a writable device. Move both `ReadOnlyDevice` and
`ReadWriteDevice` into their own modules.
The reason for the previous value was so, when restarting DrMem,
devices could be set back to their previous setting. Read-only devices
get their value from querying their hardware. You don't restore a
read-only device.
@rneswold rneswold merged commit 32fad78 into DrMemCS:main Aug 23, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant