| Message ID | 20240711-alsa-kselftest-board-name-v1-1-ab5cf2dbbea6@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kselftest/alsa: Use card name rather than number in test names | expand |
On 11. 07. 24 16:33, Mark Brown wrote: > Currently for the PCM and mixer tests we report test names which identify > the card being tested with the card number. This ensures we have unique > names but since card numbers are dynamically assigned at runtime the names > we end up with will often not be stable on systems with multiple cards > especially where those cards are provided by separate modules loeaded at > runtime. This makes it difficult for automated systems and UIs to relate > test results between runs on affected platforms. > > Address this by replacing our use of card numbers with card names which are > more likely to be stable across runs. We use the long name since in the > case where we have two of the same card it is more likely to include > deduplication information (eg, HDA cards include the address/IRQ). The > resulting information is not the most beautiful for human readers but the > majority of kselftest output consumption is automated systems and it wasn't > that great anyway. > > Signed-off-by: Mark Brown <broonie@kernel.org> I think that a combination of card number and card ID may be sufficient (and a compromise). It's shorter and user-friendly. Additionally, a table may be printed at the beginning of report with card number, card ID and long card name for further processing and identification. Jaroslav
On Thu, Jul 11, 2024 at 06:08:38PM +0200, Jaroslav Kysela wrote: > On 11. 07. 24 16:33, Mark Brown wrote: > > Address this by replacing our use of card numbers with card names which are > > more likely to be stable across runs. We use the long name since in the > I think that a combination of card number and card ID may be sufficient (and > a compromise). It's shorter and user-friendly. Additionally, a table may be > printed at the beginning of report with card number, card ID and long card > name for further processing and identification. These don't help, the problem is that anything which includes the card number in the test name result is going to result in unstable test names depending on race conditions at boot. There are automated systems that parse kselftest output generically, I'm not sure there's a great deal of enthusiasm for writing a custom parser for the ALSA selftests specifically.
On Thu, 11 Jul 2024 18:19:25 +0200, Mark Brown wrote: > > On Thu, Jul 11, 2024 at 06:08:38PM +0200, Jaroslav Kysela wrote: > > On 11. 07. 24 16:33, Mark Brown wrote: > > > > Address this by replacing our use of card numbers with card names which are > > > more likely to be stable across runs. We use the long name since in the > > > I think that a combination of card number and card ID may be sufficient (and > > a compromise). It's shorter and user-friendly. Additionally, a table may be > > printed at the beginning of report with card number, card ID and long card > > name for further processing and identification. > > These don't help, the problem is that anything which includes the card > number in the test name result is going to result in unstable test names > depending on race conditions at boot. There are automated systems that > parse kselftest output generically, I'm not sure there's a great deal of > enthusiasm for writing a custom parser for the ALSA selftests > specifically. OTOH, longname can be really ugly to read, and it can vary because it often embeds address or irq numbers in the string. If a general name is the goal, how about using shortname instead? Or use id field, as Jaroslav suggested, but without the card number suffix; then it's unique among multiple cards. thanks, Takashi
On 12. 07. 24 10:21, Takashi Iwai wrote: > On Thu, 11 Jul 2024 18:19:25 +0200, > Mark Brown wrote: >> >> On Thu, Jul 11, 2024 at 06:08:38PM +0200, Jaroslav Kysela wrote: >>> On 11. 07. 24 16:33, Mark Brown wrote: >> >>>> Address this by replacing our use of card numbers with card names which are >>>> more likely to be stable across runs. We use the long name since in the >> >>> I think that a combination of card number and card ID may be sufficient (and >>> a compromise). It's shorter and user-friendly. Additionally, a table may be >>> printed at the beginning of report with card number, card ID and long card >>> name for further processing and identification. >> >> These don't help, the problem is that anything which includes the card >> number in the test name result is going to result in unstable test names >> depending on race conditions at boot. There are automated systems that >> parse kselftest output generically, I'm not sure there's a great deal of >> enthusiasm for writing a custom parser for the ALSA selftests >> specifically. > > OTOH, longname can be really ugly to read, and it can vary because it > often embeds address or irq numbers in the string. > > If a general name is the goal, how about using shortname instead? > > Or use id field, as Jaroslav suggested, but without the card number > suffix; then it's unique among multiple cards. I prefer this (use only ID field). This string can be also set in the user space using sysfs/udev, so the administrator may change it if the default is not ideal. Jaroslav
On Fri, Jul 12, 2024 at 11:20:05AM +0200, Jaroslav Kysela wrote: > On 12. 07. 24 10:21, Takashi Iwai wrote: > > OTOH, longname can be really ugly to read, and it can vary because it > > often embeds address or irq numbers in the string. Capturing that variation is one of the goals - it should mostly be stable between runs. > > If a general name is the goal, how about using shortname instead? > > Or use id field, as Jaroslav suggested, but without the card number > > suffix; then it's unique among multiple cards. > I prefer this (use only ID field). This string can be also set in the user > space using sysfs/udev, so the administrator may change it if the default is > not ideal. The trouble with the ID field is that it's too short and seems likely to create collisions, for example HDA stuff just seems to default to NVidia for nVidia cards which seems very likely to create collisions if someone has two graphics cards in their system.
On 12. 07. 24 15:00, Mark Brown wrote: > On Fri, Jul 12, 2024 at 11:20:05AM +0200, Jaroslav Kysela wrote: >> On 12. 07. 24 10:21, Takashi Iwai wrote: > >>> OTOH, longname can be really ugly to read, and it can vary because it >>> often embeds address or irq numbers in the string. > > Capturing that variation is one of the goals - it should mostly be > stable between runs. > >>> If a general name is the goal, how about using shortname instead? > >>> Or use id field, as Jaroslav suggested, but without the card number >>> suffix; then it's unique among multiple cards. > >> I prefer this (use only ID field). This string can be also set in the user >> space using sysfs/udev, so the administrator may change it if the default is >> not ideal. > > The trouble with the ID field is that it's too short and seems likely to > create collisions, for example HDA stuff just seems to default to NVidia > for nVidia cards which seems very likely to create collisions if someone > has two graphics cards in their system. The default IDs are always unique - see snd_card_set_id_no_lock() in sound/core/init.c . Basically, the suffix will follow the device probe order in this case. Jaroslav
On Fri, Jul 12, 2024 at 06:25:21PM +0200, Jaroslav Kysela wrote: > On 12. 07. 24 15:00, Mark Brown wrote: > > The trouble with the ID field is that it's too short and seems likely to > > create collisions, for example HDA stuff just seems to default to NVidia > > for nVidia cards which seems very likely to create collisions if someone > > has two graphics cards in their system. > The default IDs are always unique - see snd_card_set_id_no_lock() in > sound/core/init.c . Basically, the suffix will follow the device probe order > in this case. Sure, but the genesis of this patch is that probe order isn't sufficiently stable and we want to avoid names based on it... using the ID will be more likely to work out stable than just pure probe order but it's still got the same issue.
On Fri, 12 Jul 2024 20:19:33 +0200, Mark Brown wrote: > > On Fri, Jul 12, 2024 at 06:25:21PM +0200, Jaroslav Kysela wrote: > > On 12. 07. 24 15:00, Mark Brown wrote: > > > > The trouble with the ID field is that it's too short and seems likely to > > > create collisions, for example HDA stuff just seems to default to NVidia > > > for nVidia cards which seems very likely to create collisions if someone > > > has two graphics cards in their system. > > > The default IDs are always unique - see snd_card_set_id_no_lock() in > > sound/core/init.c . Basically, the suffix will follow the device probe order > > in this case. > > Sure, but the genesis of this patch is that probe order isn't > sufficiently stable and we want to avoid names based on it... using the > ID will be more likely to work out stable than just pure probe order but > it's still got the same issue. Are you trying to solve the issue with two cards of the same driver, which are swapped sometimes at the probe time? Or the mixture of different cards that are swapped? In the latter case, id should work well. The id is primarily created from the (short)name string, and the suffix is added only when conflicting. OTOH, if the former is the problem, using longname won't help, either, rather it can be confusing. I noticed that the test output truncates the name string, hence both cards look identical in the actual output (except for the card listing at the beginning). Takashi
On 12. 07. 24 20:19, Mark Brown wrote: > On Fri, Jul 12, 2024 at 06:25:21PM +0200, Jaroslav Kysela wrote: >> On 12. 07. 24 15:00, Mark Brown wrote: > >>> The trouble with the ID field is that it's too short and seems likely to >>> create collisions, for example HDA stuff just seems to default to NVidia >>> for nVidia cards which seems very likely to create collisions if someone >>> has two graphics cards in their system. > >> The default IDs are always unique - see snd_card_set_id_no_lock() in >> sound/core/init.c . Basically, the suffix will follow the device probe order >> in this case. > > Sure, but the genesis of this patch is that probe order isn't > sufficiently stable and we want to avoid names based on it... using the > ID will be more likely to work out stable than just pure probe order but > it's still got the same issue. The probe order is almost stable for the drivers with the non-deferred probe. Also, administrators may set persistent ID for complex hardware configuration cases based on other keys like serial number or so (sysfs/udev). For long name - the device path may change (USB moved to different port, PCI card moved to different slot), so the stability of this string is also questionable. Jaroslav
On Sat, Jul 13, 2024 at 09:35:36AM +0200, Jaroslav Kysela wrote: > On 12. 07. 24 20:19, Mark Brown wrote: > > Sure, but the genesis of this patch is that probe order isn't > > sufficiently stable and we want to avoid names based on it... using the > > ID will be more likely to work out stable than just pure probe order but > > it's still got the same issue. > The probe order is almost stable for the drivers with the non-deferred > probe. Also, administrators may set persistent ID for complex hardware It's not very stable for modules being loaded, there's enough going on and enough module loads happening simultaneously that it's very easy for drivers to come up in different orders. I'm seeing these issues quite frequently in my test farm. > configuration cases based on other keys like serial number or so > (sysfs/udev). For a lot of test scenarios that's just not really relevant - with a pool of machines any per machine keys get hard to manage, and for something like kernelci.org customising the rootfs for even classes of boards never mind specific boards is going to be an unreasonable ask. > For long name - the device path may change (USB moved to different port, PCI > card moved to different slot), so the stability of this string is also > questionable. The concern here is repeated boots on the same system in an automated context, if someone changes the hardware then it's reasonable that the set of cards would change.
On Sat, Jul 13, 2024 at 08:46:43AM +0200, Takashi Iwai wrote: > Mark Brown wrote: > > Sure, but the genesis of this patch is that probe order isn't > > sufficiently stable and we want to avoid names based on it... using the > > ID will be more likely to work out stable than just pure probe order but > > it's still got the same issue. > Are you trying to solve the issue with two cards of the same driver, > which are swapped sometimes at the probe time? Or the mixture of > different cards that are swapped? The one I'm running into personally is due to the load order of the sound card drivers themselves, but it seems good to try to address the issue in general especially with ASoC where you're waiting for multiple drivers for individual components in the card. That means that even for a single driver the ordering might not be stable. > In the latter case, id should work well. The id is primarily created > from the (short)name string, and the suffix is added only when > conflicting. Yeah, it's more stable but there's still a potential issue. > OTOH, if the former is the problem, using longname won't help, > either, rather it can be confusing. I noticed that the test output > truncates the name string, hence both cards look identical in the > actual output (except for the card listing at the beginning). Interesting - I was mainly developing on a system with multiple HDA cards and was getting fairly clearly unique names.
On Mon, 15 Jul 2024 15:18:44 +0200, Mark Brown wrote: > > On Sat, Jul 13, 2024 at 08:46:43AM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > OTOH, if the former is the problem, using longname won't help, > > either, rather it can be confusing. I noticed that the test output > > truncates the name string, hence both cards look identical in the > > actual output (except for the card listing at the beginning). > > Interesting - I was mainly developing on a system with multiple HDA > cards and was getting fairly clearly unique names. An AMD system usually has two HD-audio entries, and both are "HD-audio Generic". Takashi
On Mon, Jul 15, 2024 at 03:23:24PM +0200, Takashi Iwai wrote: > Mark Brown wrote: > > Interesting - I was mainly developing on a system with multiple HDA > > cards and was getting fairly clearly unique names. > An AMD system usually has two HD-audio entries, and both are "HD-audio > Generic". Right, that won't do. My legacy system here is getting the addresses in there so deduplicates successfully.
diff --git a/tools/testing/selftests/alsa/mixer-test.c b/tools/testing/selftests/alsa/mixer-test.c index 1c04e5f638a0..df9ae3b4e2df 100644 --- a/tools/testing/selftests/alsa/mixer-test.c +++ b/tools/testing/selftests/alsa/mixer-test.c @@ -33,6 +33,7 @@ struct card_data { snd_ctl_t *handle; int card; + const char *card_name; struct pollfd pollfd; int num_ctls; snd_ctl_elem_list_t *ctls; @@ -91,6 +92,7 @@ static void find_controls(void) err = snd_card_get_longname(card, &card_longname); if (err != 0) card_longname = "Unknown"; + card_data->card_name = card_longname; ksft_print_msg("Card %d - %s (%s)\n", card, card_name, card_longname); @@ -389,16 +391,16 @@ static void test_ctl_get_value(struct ctl_data *ctl) /* If the control is turned off let's be polite */ if (snd_ctl_elem_info_is_inactive(ctl->info)) { ksft_print_msg("%s is inactive\n", ctl->name); - ksft_test_result_skip("get_value.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("get_value.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } /* Can't test reading on an unreadable control */ if (!snd_ctl_elem_info_is_readable(ctl->info)) { ksft_print_msg("%s is not readable\n", ctl->name); - ksft_test_result_skip("get_value.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("get_value.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } @@ -413,8 +415,8 @@ static void test_ctl_get_value(struct ctl_data *ctl) err = -EINVAL; out: - ksft_test_result(err >= 0, "get_value.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(err >= 0, "get_value.%s.%d\n", + ctl->card->card_name, ctl->elem); } static bool strend(const char *haystack, const char *needle) @@ -431,7 +433,7 @@ static void test_ctl_name(struct ctl_data *ctl) { bool name_ok = true; - ksft_print_msg("%d.%d %s\n", ctl->card->card, ctl->elem, + ksft_print_msg("%s.%d %s\n", ctl->card->card_name, ctl->elem, ctl->name); /* Only boolean controls should end in Switch */ @@ -453,8 +455,8 @@ static void test_ctl_name(struct ctl_data *ctl) } } - ksft_test_result(name_ok, "name.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(name_ok, "name.%s.%d\n", + ctl->card->card_name, ctl->elem); } static void show_values(struct ctl_data *ctl, snd_ctl_elem_value_t *orig_val, @@ -682,30 +684,30 @@ static void test_ctl_write_default(struct ctl_data *ctl) /* If the control is turned off let's be polite */ if (snd_ctl_elem_info_is_inactive(ctl->info)) { ksft_print_msg("%s is inactive\n", ctl->name); - ksft_test_result_skip("write_default.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_default.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } if (!snd_ctl_elem_info_is_writable(ctl->info)) { ksft_print_msg("%s is not writeable\n", ctl->name); - ksft_test_result_skip("write_default.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_default.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } /* No idea what the default was for unreadable controls */ if (!snd_ctl_elem_info_is_readable(ctl->info)) { ksft_print_msg("%s couldn't read default\n", ctl->name); - ksft_test_result_skip("write_default.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_default.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } err = write_and_verify(ctl, ctl->def_val, NULL); - ksft_test_result(err >= 0, "write_default.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(err >= 0, "write_default.%s.%d\n", + ctl->card->card_name, ctl->elem); } static bool test_ctl_write_valid_boolean(struct ctl_data *ctl) @@ -815,15 +817,15 @@ static void test_ctl_write_valid(struct ctl_data *ctl) /* If the control is turned off let's be polite */ if (snd_ctl_elem_info_is_inactive(ctl->info)) { ksft_print_msg("%s is inactive\n", ctl->name); - ksft_test_result_skip("write_valid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_valid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } if (!snd_ctl_elem_info_is_writable(ctl->info)) { ksft_print_msg("%s is not writeable\n", ctl->name); - ksft_test_result_skip("write_valid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_valid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } @@ -846,16 +848,16 @@ static void test_ctl_write_valid(struct ctl_data *ctl) default: /* No tests for this yet */ - ksft_test_result_skip("write_valid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_valid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } /* Restore the default value to minimise disruption */ write_and_verify(ctl, ctl->def_val, NULL); - ksft_test_result(pass, "write_valid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(pass, "write_valid.%s.%d\n", + ctl->card->card_name, ctl->elem); } static bool test_ctl_write_invalid_value(struct ctl_data *ctl, @@ -1027,15 +1029,15 @@ static void test_ctl_write_invalid(struct ctl_data *ctl) /* If the control is turned off let's be polite */ if (snd_ctl_elem_info_is_inactive(ctl->info)) { ksft_print_msg("%s is inactive\n", ctl->name); - ksft_test_result_skip("write_invalid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_invalid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } if (!snd_ctl_elem_info_is_writable(ctl->info)) { ksft_print_msg("%s is not writeable\n", ctl->name); - ksft_test_result_skip("write_invalid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_invalid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } @@ -1058,28 +1060,28 @@ static void test_ctl_write_invalid(struct ctl_data *ctl) default: /* No tests for this yet */ - ksft_test_result_skip("write_invalid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result_skip("write_invalid.%s.%d\n", + ctl->card->card_name, ctl->elem); return; } /* Restore the default value to minimise disruption */ write_and_verify(ctl, ctl->def_val, NULL); - ksft_test_result(pass, "write_invalid.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(pass, "write_invalid.%s.%d\n", + ctl->card->card_name, ctl->elem); } static void test_ctl_event_missing(struct ctl_data *ctl) { - ksft_test_result(!ctl->event_missing, "event_missing.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(!ctl->event_missing, "event_missing.%s.%d\n", + ctl->card->card_name, ctl->elem); } static void test_ctl_event_spurious(struct ctl_data *ctl) { - ksft_test_result(!ctl->event_spurious, "event_spurious.%d.%d\n", - ctl->card->card, ctl->elem); + ksft_test_result(!ctl->event_spurious, "event_spurious.%s.%d\n", + ctl->card->card_name, ctl->elem); } int main(void) diff --git a/tools/testing/selftests/alsa/pcm-test.c b/tools/testing/selftests/alsa/pcm-test.c index de664dedb541..a7b1e6e876c5 100644 --- a/tools/testing/selftests/alsa/pcm-test.c +++ b/tools/testing/selftests/alsa/pcm-test.c @@ -24,6 +24,7 @@ typedef struct timespec timestamp_t; struct card_data { int card; + const char *name; pthread_t thread; struct card_data *next; }; @@ -35,6 +36,7 @@ struct pcm_data { int card; int device; int subdevice; + const char *card_name; snd_pcm_stream_t stream; snd_config_t *pcm_config; struct pcm_data *next; @@ -191,6 +193,7 @@ static void find_pcms(void) if (!card_data) ksft_exit_fail_msg("Out of memory\n"); card_data->card = card; + card_data->name = card_longname; card_data->next = card_list; card_list = card_data; @@ -232,6 +235,7 @@ static void find_pcms(void) pcm_data->card = card; pcm_data->device = dev; pcm_data->subdevice = subdev; + pcm_data->card_name = card_name; pcm_data->stream = stream; pcm_data->pcm_config = conf_get_subtree(card_config, key, NULL); pcm_data->next = pcm_list; @@ -294,9 +298,9 @@ static void test_pcm_time(struct pcm_data *data, enum test_class class, desc = conf_get_string(pcm_cfg, "description", NULL, NULL); if (desc) - ksft_print_msg("%s.%s.%d.%d.%d.%s - %s\n", + ksft_print_msg("%s.%s.%s.%d.%d.%s - %s\n", test_class_name, test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, data->subdevice, snd_pcm_stream_name(data->stream), desc); @@ -352,9 +356,9 @@ static void test_pcm_time(struct pcm_data *data, enum test_class class, old_format = format; format = snd_pcm_format_value(alt_formats[i]); if (format != SND_PCM_FORMAT_UNKNOWN) { - ksft_print_msg("%s.%d.%d.%d.%s.%s format %s -> %s\n", + ksft_print_msg("%s.%s.%d.%d.%s.%s format %s -> %s\n", test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, data->subdevice, snd_pcm_stream_name(data->stream), snd_pcm_access_name(access), snd_pcm_format_name(old_format), @@ -430,9 +434,9 @@ static void test_pcm_time(struct pcm_data *data, enum test_class class, goto __close; } - ksft_print_msg("%s.%s.%d.%d.%d.%s hw_params.%s.%s.%ld.%ld.%ld.%ld sw_params.%ld\n", + ksft_print_msg("%s.%s.%s.%d.%d.%s hw_params.%s.%s.%ld.%ld.%ld.%ld sw_params.%ld\n", test_class_name, test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, data->subdevice, snd_pcm_stream_name(data->stream), snd_pcm_access_name(access), snd_pcm_format_name(format), @@ -491,9 +495,10 @@ static void test_pcm_time(struct pcm_data *data, enum test_class class, * Anything specified as specific to this system * should always be supported. */ - ksft_test_result(!skip, "%s.%s.%d.%d.%d.%s.params\n", + ksft_test_result(!skip, "%s.%s.%s.%d.%d.%s.params\n", test_class_name, test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, + data->subdevice, snd_pcm_stream_name(data->stream)); break; default: @@ -501,14 +506,16 @@ static void test_pcm_time(struct pcm_data *data, enum test_class class, } if (!skip) - ksft_test_result(pass, "%s.%s.%d.%d.%d.%s\n", + ksft_test_result(pass, "%s.%s.%s.%d.%d.%s\n", test_class_name, test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, + data->subdevice, snd_pcm_stream_name(data->stream)); else - ksft_test_result_skip("%s.%s.%d.%d.%d.%s\n", + ksft_test_result_skip("%s.%s.%s.%d.%d.%s\n", test_class_name, test_name, - data->card, data->device, data->subdevice, + data->card_name, data->device, + data->subdevice, snd_pcm_stream_name(data->stream)); if (msg[0]) @@ -609,8 +616,8 @@ int main(void) conf->filename, conf->config_id); for (pcm = pcm_missing; pcm != NULL; pcm = pcm->next) { - ksft_test_result(false, "test.missing.%d.%d.%d.%s\n", - pcm->card, pcm->device, pcm->subdevice, + ksft_test_result(false, "test.missing.%s.%d.%d.%s\n", + pcm->card_name, pcm->device, pcm->subdevice, snd_pcm_stream_name(pcm->stream)); }
Currently for the PCM and mixer tests we report test names which identify the card being tested with the card number. This ensures we have unique names but since card numbers are dynamically assigned at runtime the names we end up with will often not be stable on systems with multiple cards especially where those cards are provided by separate modules loeaded at runtime. This makes it difficult for automated systems and UIs to relate test results between runs on affected platforms. Address this by replacing our use of card numbers with card names which are more likely to be stable across runs. We use the long name since in the case where we have two of the same card it is more likely to include deduplication information (eg, HDA cards include the address/IRQ). The resulting information is not the most beautiful for human readers but the majority of kselftest output consumption is automated systems and it wasn't that great anyway. Signed-off-by: Mark Brown <broonie@kernel.org> --- tools/testing/selftests/alsa/mixer-test.c | 76 ++++++++++++++++--------------- tools/testing/selftests/alsa/pcm-test.c | 35 ++++++++------ 2 files changed, 60 insertions(+), 51 deletions(-) --- base-commit: f2661062f16b2de5d7b6a5c42a9a5c96326b8454 change-id: 20240711-alsa-kselftest-board-name-e4a1add4cfa0 Best regards,