-
Notifications
You must be signed in to change notification settings - Fork 29
distinguish file backend thread names across backend instances #997
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| // This Source Code Form is subject to the terms of the Mozilla Public | ||
| // License, v. 2.0. If a copy of the MPL was not distributed with this | ||
| // file, You can obtain one at https://mozilla.org/MPL/2.0/. | ||
|
|
||
| //! Runtime identifiers for block devices and their backends. | ||
| //! | ||
| //! Devices that support block backends and the block backends themselves are | ||
| //! independent identifiers, and only become related when an item of each type | ||
| //! is connected via [`block::attach`]. | ||
| //! | ||
| //! Devices in particular may have multiple identifiers, some from this module | ||
| //! and some from others. As one example, [`propolis::hw::nvme::NvmeCtrl`] has a | ||
| //! `device_id` distinguishing *instances of the NVMe controller* across a VM, | ||
| //! while the `PciNvme` which has an NVMe controller also has `block_attach` | ||
| //! with a `device_id` distinguishing *instances of block devices* across a VM. | ||
| //! | ||
| //! ## Limitations | ||
| //! | ||
| //! A consumer of `propolis` is free to construct devices supporting block | ||
| //! backends in any order, and may happen to construct block backends in any | ||
| //! different arbitrary order. Attaching the two kinds of item together is also | ||
| //! up to the consumer of `propolis`, and there is no requirement that a | ||
| //! particular block backend must be connected to a particular device. | ||
| //! | ||
| //! Consequently, these identifiers are not stable for use in migration of a VM, | ||
| //! and must not be used in a way visible to a VM. They are unsuitable for | ||
| //! emulated device serial numbers, model numbers, etc. The destination | ||
| //! `propolis` may construct the same set of devices in a different order, | ||
| //! resulting in different run-time identifiers for a device at the same | ||
| //! location. | ||
|
Comment on lines
+17
to
+30
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do we provide any type of way for a consumer (such as a D script) to establish a mapping of these IDs to externally knowable objects? i see that the DTrace
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
|
||
| use crate::util::id::define_id; | ||
|
|
||
| define_id! { | ||
| /// Numbering across block devices means that a block `DeviceId` and the | ||
| /// queue ID in a block attachment are unique across a VM. | ||
| #[derive(Copy, Clone)] | ||
| pub struct DeviceId(pub(crate) u32); | ||
| } | ||
|
|
||
| define_id! { | ||
| /// Block backends are numbered distinctly across a VM, but may not | ||
| /// be created in the same order as devices. The `block_attach` probe fires | ||
| /// when a `DeviceId` and `BackendId` become associated. | ||
| #[derive(Copy, Clone)] | ||
| pub struct BackendId(pub(crate) u32); | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.