zephyrproject-rtos/zephyr

tests: posix: common: separate into smaller testsuites

オープン

#79,454 opened on 2024/10/05

 (9 件のコメント) (0 件のリアクション) (1 人の担当者)C (9,144 件のフォーク)batch import
EnhancementGood first issuearea: POSIXarea: Tests

Repository metrics

Stars
 (15,249 個のスター)
PR merge metrics
 (平均マージ 4d 21h) (30d で 1,000 merged PRs)

説明

Is your enhancement proposal related to a problem? Please describe. The posix.common testsuite contains a lot of mostly unrelated testsuites. As a result, the code size is large, but mostly the data size is extremely large.

It would require less variation from default settings, and would reduce ram requirements to split that testsuite into smaller groups of more closely related testsuites.

Describe the solution you'd like

The obvious way to group related testsuites is by Option Group.

E.g.

  • POSIX_BARRIERS - #81487
  • POSIX_C_LIB_EXT - #81488
  • POSIX_RW_LOCKS - #80943
  • POSIX_SEMAPHORES - #80964
  • POSIX_SIGNALS - #80930
  • POSIX_SINGLE_PROCESS - #80981
  • POSIX_SPIN_LOCKS - #80965
  • POSIX_SYSTEM_DATABASE - #81489
  • POSIX_THREADS_BASE - #81491
  • POSIX_THREADS_EXT - #81490
  • POSIX_TIMERS - #80807
  • XSI_REALTIME - #83634
  • XSI_REALTIME_THREADS - #86042
  • XSI_SYSTEM_LOGGING - #80986
  • XSI_THREADS_EXT - #81741

and potentially others.

testcase.yaml permutations can be designed to enable or disable features that affect different Option Groups, like TSS, TSA, TSH (see Codes).

Additionally, such a grouping would theoretically improve bug attribution capabilities; if an error was traced (either via stacktrace or bug description) to a certain posix function, there would be a 1:1 correspondance to an Option Group, so typically, only that testsuite would need to be executed.

Describe alternatives you've considered The way the testsuite has been designed historically.

Additional context This came up in the context of #79443 but it was already thought of as a nice-to-have.

コントリビューターガイド