zephyrproject-rtos/zephyr

tests: posix: common: separate into smaller testsuites

已关闭

#79,454 创建于 2024年10月5日

 (9 条评论) (0 个反应) (1 位负责人)C (9,144 个派生)batch import
EnhancementGood first issuearea: POSIXarea: Tests

仓库指标

星标
 (15,249 个星标)
PR 合并指标
 (平均合并 4天 21小时) (30 天内合并 1,000 个 PR)

描述

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.

贡献者指南