Re: [PATCH 1/1] selftests: sync: add config fragment for testing sync framework

[Fathi Boudra]

On 11 May 2017 at 07:52, Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:
> Fathi Boudra <fathi.boudra@xxxxxxxxxx> writes:
>
>> Unless the software synchronization objects (CONFIG_SW_SYNC) is enabled,
>> the sync test will fail:
>>
>> Additional Information:
>> Running tests in sync
>> ========================================
>> [RUN]   Testing sync framework
>> [RUN]   Executing test_alloc_timeline
>> [ERROR] Failure allocating timeline
>
> It would be better if the test just detected that the kernel didn't
> support the API.

It makes sense to me. The sync framework has been introduced from 4.8 kernel.
It resolves the case where we run an older kernel like 4.4 LTS with a
recent kselftest.

> It seems to rely on /sys/kernel/debug/sync/sw_sync existing.
>
> How about this?

fwiw, looks good to me. I think we still need the config fragment to
leverage kselftest-merge.

> diff --git a/tools/testing/selftests/sync/sync_test.c b/tools/testing/selftests/sync/sync_test.c
> index 9ea08d9f0b13..62fa666e501a 100644
> --- a/tools/testing/selftests/sync/sync_test.c
> +++ b/tools/testing/selftests/sync/sync_test.c
> @@ -29,6 +29,7 @@
>  #include <unistd.h>
>  #include <stdlib.h>
>  #include <sys/types.h>
> +#include <sys/stat.h>
>  #include <sys/wait.h>
>
>  #include "synctest.h"
> @@ -52,10 +53,22 @@ static int run_test(int (*test)(void), char *name)
>         exit(test());
>  }
>
> +static int sync_api_supported(void)
> +{
> +       struct stat sbuf;
> +
> +       return 0 == stat("/sys/kernel/debug/sync/sw_sync", &sbuf);
> +}
> +
>  int main(void)
>  {
>         int err = 0;
>
> +       if (!sync_api_supported()) {
> +               printf("SKIP: Sync framework not supported by kernel\n");
> +               return 0;
> +       }
> +
>         printf("[RUN]\tTesting sync framework\n");
>
>         err += RUN_TEST(test_alloc_timeline);
>
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html