Skip to content

Conversation

tasleson
Copy link
Contributor

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.

Copy link

Hey @tasleson, a file(s) you own were modified in this PR! Could you take a look?


Caused by:

Copy link

Hey @nfont, a file(s) you own were modified in this PR! Could you take a look?


Caused by:

Copy link

Hey @prabhakar, a file(s) you own were modified in this PR! Could you take a look?


Caused by:

@bkucman
Copy link
Contributor

bkucman commented Sep 15, 2025

Hi,
I'm ok with this change, just some minor tweaks to make.

@tasleson
Copy link
Contributor Author

Thanks for the review. Any suggestions on adding this for different controller types?

@mtkaczyk
Copy link
Contributor

HI @tasleson,
I don't see it integrated with ledctl, am I correct?

LGTM, to me but I would split it into two PRs first with fixes, the second with feature.

@tasleson
Copy link
Contributor Author

HI @tasleson,
I don't see it integrated with ledctl, am I correct?

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.

@tasleson
Copy link
Contributor Author

@mtkaczyk I broke this into 2 pull requests, the other is #269 which needs to be commited before this one.

@tasleson
Copy link
Contributor Author

tasleson commented Oct 1, 2025

@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>
@tasleson tasleson requested a review from bkucman October 1, 2025 14:22
Copy link
Contributor

@bkucman bkucman left a 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 :)

@bkucman
Copy link
Contributor

bkucman commented Oct 3, 2025

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.

@bkucman bkucman merged commit 005eb5b into intel:main Oct 3, 2025
10 of 11 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