-
Notifications
You must be signed in to change notification settings - Fork 169
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
Conversation
Fixes #1604 |
ef135bb
to
f3b1939
Compare
// in the array which is also going to be less than `u8` | ||
let idx = match u8::try_from(i) { | ||
Ok(v) => v, | ||
Err(_) => unreachable!(), |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 => { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
No description provided.