POSIX Roadmap for LTSv3 #51211
Assignees
Labels
Comments
cfriedt
added
RFC
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Nov 21, 2022
Define `PTHREAD_CREATE_DETACHED` and `PTHREAD_CREATE_JOINABLE` to be compatible with the Newlib definitions. This is a temporary workaround for zephyrproject-rtos#51211 until Newlib headers are pulled in. Signed-off-by: Chris Friedt <cfriedt@meta.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Nov 21, 2022
Define `PTHREAD_CREATE_DETACHED` and `PTHREAD_CREATE_JOINABLE` to be compatible with the Newlib definitions. This is a temporary workaround for zephyrproject-rtos#51211 until Newlib headers are pulled in. Signed-off-by: Chris Friedt <cfriedt@meta.com>
13 tasks
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 6, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 6, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 7, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 8, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 9, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 9, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 10, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
|
Updated comment to reflect that the the posix device_io, signals, and fd_mgmt features were reverted. This puts LTSv3 in a kind of dilapidated state from the POSIX & libc perspective. |
cfriedt
added a commit
to cfriedt/zephyr
that referenced
this issue
Jul 12, 2024
A shortcut was taken many years ago by "cherry-picking" the POSIX off_t and ssize_t types for use throughout Zephyr. Additionally, the POSIX header fcntl.h, as well as constants defined in that header, were being used inappropriately throughout Zephyr. Doing so created a dependency cycle: below POSIX's position in the stack, code depended on POSIX; above POSIX's position in the stack, code depends on the lower parts. Such dependency cycles usually result in fragility and instability of the software stack. Use the newly defined k_off_t and k_ssize_t types throughout Zephyr's stack, where off_t and ssize_t were previously used inappropriately. Additionally, use ZVFS-prefixed constants instead of their POSIX counterparts. Additionally, where appropriate, ensure the POSIX fcntl.h header is prefixed with <zephyr/posix/fcntl.h>. We effectively create a mutual dependency to resolve the cyclic dependency, as described in GitHub issue zephyrproject-rtos#51211. For clarification, it is inappropriate to use POSIX types or functions within the kernel, core OS, OS services, or really anywhere that is not equal to or above POSIX's position in the software stack. In other words, if a library uses POSIX, Zephyr's POSIX implementation cannot depend on that library. Similarly, if a system service uses POSIX, Zephyr's POSIX implementation cannot depend on that system service. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Introduction
POSIX libraries and applications should Just Work™️ in 90% of the cases when being ported to Zephyr. Why? Because we want to enable our users to launch products and applications to the best of our ability, and we want to lower the barrier to entry by enabling users to leverage portable APIs.
This is an umbrella issue that will outlines work to be done in the POSIX API prior to LTSv3 (Ideally complete by v3.5).
Problem description
As discussed at EOSS 2023 and EOSS 2024, Zephyr's POSIX API layer needs some improvements. These can be broken down into the following:
Proposed change
Implement all Option Requirements of POSIX Subprofiling Option Groups required for PSE51, PSE52, and most of PSE53 compatibility.
Update the POSIX areas at docs.zephyrproject.org. For reference, the top level page of Zephyr's POSIX documentation.
https://docs.zephyrproject.org/latest/services/portability/posix/index.html
Maintainability addresses the needs of the maintainer, contributors, and (to some extent) the users.
Interface addresses the needs of
_POSIX_C_SOURCE,_XOPEN_SOURCE)_POSIX_TIMERS)Portability addresses the needs of the users who should (rightfully) expect that the POSIX API layer behaves according to the specification.
Detailed RFC
Proposed change (Detailed)
Maintainability
subsys/net,subsys/fs, andlib/posix#include_nextis required for the aboveCONFIG_ARCH_POSIXandCONFIG_POSIX_APIare mutually exclusiveCONFIG_NET_SOCKETS_POSIX_NAMESCONFIG_POSIX_APIin spite of the fact that the BSD Sockets API is part of POSIXThe layering issues that exist between
subsys/netandlib/posixcan be described as a cyclic dependency. The issue can be resolved via mutual dependency.I.e. Currently, we have:
But we need
Diagrams made with https://asciiflow.com/
I think we may have settled on the name "ZVFS" in the above diagram.
Interface
Tip
Check the Current status of Suprofiling Option Group support from docs to verify that the items below are up to date
CONFIG_POSIX_API, Ensure POSIX headers can be included as#include <poll.h>rather than#include <zephyr/posix/poll.h>POSIX_SINGLE_PROCESSconfstr()#66866environ#66861getenv()#66862setenv()#66863sysconf()#56670uname()#59924unsetenv()#66864POSIX_SIGNALSsigaction()#59925sigaddset()#59927sigdelset()#59928sigemptyset()#59929sigfillset()#59931sigismember()#59932sigpending()#59933alarm()#66923kill()#66924pause()#66925sigprocmask()#66928sigsuspend()#66929sigwait()#66930POSIX_DEVICE_IOfdopen()#66932fileno()#66938pread()#66946pselect()#66947pwrite()#66948POSIX_FD_MGMTdup()#74097dup2()#74098fseeko()#74099ftello()#74100POSIX_SEMAPHORESsem_close()#66955sem_open()#66956sem_unlink()#66957_POSIX_MESSAGE_PASSINGmq_notify()#66958_POSIX_PRIORITY_SCHEDULINGsched_getparam()#66959sched_getscheduler()#66960sched_rr_get_interval()#66961sched_setparam()#66962sched_setscheduler()#66963_POSIX_READER_WRITER_LOCKSpthread_rwlockattr_getpshared()#66964pthread_rwlockattr_setpshared()#66965_POSIX_THREAD_PRIORITY_SCHEDULINGpthread_attr_getinheritsched()#66966pthread_attr_getscope()#66967pthread_attr_setinheritsched()#66968pthread_attr_setscope()#66969_POSIX_TIMEOUTSmq_timedreceive()#66970mq_timedsend()#66971posix_trace_timedgetnext_event()#66972_XOPEN_STREAMSfattach()#66973fdetach()#66974getmsg()#66975getpmsg()#66976isastream()#66977putmsg()#66978putpmsg()#66979_POSIX_SPIN_LOCKS(mandatory for the base specification)pthread_spin_destroy()pthread_spin_init()pthread_spin_lock()pthread_spin_trylock()pthread_spin_unlock()_POSIX_THREADSpthread_atfork()#59934pthread_barrierattr_destroy()#59935pthread_barrierattr_init()#59936pthread_barrierattr_getpshared()#59937pthread_barrierattr_setpshared()#59939pthread_cleanup_pop()#59940pthread_cleanup_push()#59941pthread_equal()#59942pthread_kill()#59943pthread_sigmask()#59944pthread_setcanceltype()#59945pthread_testcancel()#59946_POSIX_CLOCK_SELECTIONpthread_condattr_getclock()#59947pthread_condattr_setclock()#59948clock_nanosleep()#59949_POSIX_SHARED_MEMORY_OBJECTSmmap()#59950munmap()#59951shm_open()#59952shm_unlink()#59953_POSIX_CPUTIMEclock_getcpuclockid()#59954_POSIX_TIMERSclock_getres()#59955timer_getoverrun()#59956_POSIX_REALTIME_SIGNALSsigqueue()#74993sigtimedwait()#74994sigwaitinfo()#74995_POSIX_SYNCHRONIZED_IOfsync()msync()fdatasync()#74455_POSIX_THREAD_PRIO_PROTECTpthread_mutex_getprioceiling()#74456pthread_mutex_setprioceiling()#74457pthread_mutexattr_getprioceiling()#74458pthread_mutexattr_setprioceiling()#74459pthread_mutexattr_setprotocol()#74460_POSIX_THREAD_SAFE_FUNCTIONSflockfile()#74461funlockfile()#74462ftrylockfile()#74463putc_unlocked()#74464putchar_unlocked()#74465getc_unlocked()#74466getchar_unlocked()#74467asctime_r()#74468ctime_r()#74469localtime_r()#74470getgrgid_r()#74471getgrnam_r()#74472getpwnam_r()#74473getpwuid_r()#74474readdir_r()#74475Dependencies
Concerns and Unresolved Questions
Alternatives
There was a previous massive PR that attempted to address a number of the goals at once (#43987), but it is impossible to review in the current state and needs to be broken down and simplified in separate individual PRs.
The text was updated successfully, but these errors were encountered: