-
Notifications
You must be signed in to change notification settings - Fork 50
Persistent slot ID support #262
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
Conversation
Hey @tasleson, a file(s) you own were modified in this PR! Could you take a look? Caused by: |
Hey @nfont, a file(s) you own were modified in this PR! Could you take a look? Caused by: |
Hey @prabhakar, a file(s) you own were modified in this PR! Could you take a look? Caused by: |
Hi, |
75e8dd2
to
21bb4a8
Compare
Thanks for the review. Any suggestions on adding this for different controller types? |
HI @tasleson, LGTM, to me but I would split it into two PRs first with fixes, the second with feature. |
You are correct. This change is intended for software that is managing storage over time and controlling LEDs. I don't think users that are interactively using ledctl would necessarily need this, but we could certainly add it if others think it's useful. |
21bb4a8
to
fba0a37
Compare
fba0a37
to
8e049a5
Compare
@bkucman I'll fix this PR up today. |
Slot identifiers today are assigned at discovery time, so they can shift across boots or hot-plug events. This makes it hard for callers to track a drive once it becomes unresponsive or the kernel drops it. Two public functions added. 1. bool led_slot_persistent_id_support(struct led_ctx *ctx, \ enum led_cntrl_type cntrl) Which simply returns true if persistent ID support exists for the controller type 2. char *led_slot_persistent_id(struct led_slot_list_entry *se) Which returns the persistent slot ID or NULL on non-existence or error The existing slot ID function is left untouched to avoid breaking code that may rely on its value. Rudimentary testing has been done on a single SES equipped hardware system. SES leverages an enclosure ID for creating the SES persistent ID. TODO: investigate implementing persistent IDs for other transport layers that expose the slots API. Signed-off-by: Tony Asleson <tasleson@redhat.com>
Add comprehensive test coverage for the newly added persistent slot ID functions led_slot_persistent_id_support() and led_slot_persistent_id(). The test validates correct behavior across different controller types and handles environments without SCSI controllers or hardware support. Signed-off-by: Tony Asleson <tasleson@redhat.com>
8e049a5
to
e839005
Compare
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.
Hi @tasleson,
LGTM, since Mariusz also didn't report any corrections to the code, I'm merging this change :)
For now, I don't see a need to extend this feature to other controllers. If anyone would like to extend this feature to other controllers, please do so in a new PR. |
Slot identifiers today are assigned at discovery time, so they can shift
across boots or hot-plug events. This makes it hard for callers to track
a drive once it becomes unresponsive or the kernel drops it.
Two public functions added.
bool led_slot_persistent_id_support(struct led_ctx *ctx, enum led_cntrl_type cntrl)
Which simply returns true if persistent ID support exists for the
controller type
char *led_slot_persistent_id(struct led_slot_list_entry *se)
Which returns the persistent slot ID or NULL on non-existence or error
The existing slot ID function is left untouched to avoid breaking code
that may rely on its value.
Rudimentary testing has been done on a single SES equipped hardware system.
SES leverages an enclosure ID for creating the SES persistent ID.
TODO: investigate implementing persistent IDs for other transport layers
that expose the slots API.