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

Add support for reading out the VPD lock bits via MGS #1633

Merged
merged 1 commit into from
Feb 28, 2024
Merged

Conversation

labbott
Copy link
Collaborator

@labbott labbott commented Feb 27, 2024

No description provided.

@labbott labbott marked this pull request as draft February 27, 2024 17:12
@labbott
Copy link
Collaborator Author

labbott commented Feb 27, 2024

Fixes #1604

@labbott labbott force-pushed the read_vpd branch 5 times, most recently from ef135bb to f3b1939 Compare February 28, 2024 15:37
@labbott labbott marked this pull request as ready for review February 28, 2024 15:37
// in the array which is also going to be less than `u8`
let idx = match u8::try_from(i) {
Ok(v) => v,
Err(_) => unreachable!(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this feels like it should be a panic! instead, because it's not immediately obvious that it's unreachable – it's not obvious that buf.len() <= u8::MAX, since it's caller-controlled, and cnt is a usize.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're taking at most cnt items per take (https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.take) and cnt is bounded by the total number of vpd devices. If cnt was actually larger than u8 we wouldn't be able to access anything because the other APIs would reject the index. Actually hitting unreachable would indicate a system configuration error we would most likely hit elsewhere. I can change it to a panic out of an abundance of caution but given our work on reducing panic sizes it seemed reasonable to mark it as unreachable. I can try and make the comment even more explicit.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other way to make it clear would be changing num_vpd_devices to return a u8.

(Also, is panic! more expensive than unreachable!?)

Ok(v) => v.into(),
Err(e) => {
return Err(SpError::Vpd(match e {
VpdError::InvalidDevice => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we implement From<VpdError> for GatewayVpdError?

(It would have to go in vpd-api, so maybe that's too much plumbing)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it but it seemed like overkill given the limited scope of this.

Some targets like the gimletlet have a control-plane-agent but no
VPD support, hence the creation of the vpd feature. This does introduce
some runtime overhead but the expectation is that this feature is not
performance critical.
@labbott labbott merged commit 08c2fd6 into master Feb 28, 2024
83 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.

3 participants