Skip to content

POSIX Roadmap for LTSv3 #51211

Closed
Closed
@cfriedt

Description

@cfriedt

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:

  1. Maintainability
  2. Application / libc / toolchain Interface
  3. Application / library Portability

Proposed change

Implement all Option Requirements of POSIX Subprofiling Option Groups required for PSE51, PSE52, and most of PSE53 compatibility.

aep

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

  • the user (users develop POSIX code to the interface, not the implementation) (i.e. _POSIX_C_SOURCE, _XOPEN_SOURCE)
  • the C Library maintainers - via Option Requirements (e.g. _POSIX_TIMERS)
  • users - we do not need to re-doc the standardized POSIX API (i.e. via doxygen). However, users should rightfully expect to be able to find links to the standards that Zephyr conforms to, as well as the conformance gaps.

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

The layering issues that exist between subsys/net and lib/posix can be described as a cyclic dependency. The issue can be resolved via mutual dependency.

I.e. Currently, we have:

┌───────────┐       ┌───────────┐
│           ├──────►│           │
│   POSIX   │       │   NET     │
│           │◄──────┤           │
└───────────┘       └───────────┘

But we need

          ┌───────────┐
          │           │
          │   ZVFS    │
          │           │
          └▲────────▲─┘
           │        │
           │        │
┌──────────┴┐       ├───────────┐
│           │       │           │
│   POSIX   ├───────►   NET     │
│           │       │           │
└───────────┘       └───────────┘

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

Dependencies

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.

Metadata

Metadata

Assignees

Labels

RFCRequest For Comments: want input from the communityarea: POSIXPOSIX API Library

Type

Projects

Status

3.7 (LTS3)

Status

Done

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions