Skip to content

std.os: spring-cleanup and specify organization #14726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

matu3ba
Copy link
Contributor

@matu3ba matu3ba commented Feb 25, 2023

  • Alphabetically sort things, where reasonable.
  • Document, that only non-portable posix things belong into posix.zig
    • If there is a portable abstraction, do not offer one in posix.zig
    • Reason: Prevent useless abstractions and needless strong coupling.
  • Move posix-only functions into posix.zig, which have either incompatible
    or more extensive execution semantics than their counterparts and can be
    grouped into
    • File permission system
    • Process management
    • Memory management
    • IPC
    • Signaling

Work on #6600.

@matu3ba

This comment was marked as resolved.

@matu3ba matu3ba force-pushed the cleanup_os branch 2 times, most recently from 4dde7ea to df782a3 Compare March 4, 2023 00:45
@matu3ba

This comment was marked as resolved.

@kassane
Copy link
Contributor

kassane commented Mar 5, 2023

Ref: #14795

@matu3ba
Copy link
Contributor Author

matu3ba commented Mar 7, 2023

Future TODOs

Where should linux only error abstractions go? linux.zig and move the non-error abstractions into linux/api.zig?

  • epoll_create1, epoll_ctl, epoll_wait

  • inotify_init1, inotify_add_watch, inotify_add_watchZ, inotify_rm_watch: linux

  • dl_iterate_phdr

  • sched_getaffinity

  • signalfd

  • syncfs

  • perf_event_open etc

  • timerfd_create, timerfd_gettime, timerfd_gettime (posix ones are broken)

  • maybeIgnoreSigpipe: belongs into start.zig

@matu3ba matu3ba marked this pull request as ready for review March 7, 2023 20:36
- Alphabetically sort things, where reasonable.
- Document, that **only** non-portable posix things belong into posix.zig
  * If there is a portable abstraction, do not offer one in posix.zig
  * Reason: Prevent useless abstractions and needless strong coupling.
- Move posix-only functions into posix.zig, which have either incompatible
  or more extensive execution semantics than their counterparts and can be
  grouped into
  * File permission system
  * Process management
  * Memory management
  * IPC
  * Signaling

Work on ziglang#6600.
@andrewrk
Copy link
Member

This pull request is extremely chaotic and does a lot of things that are difficult to review, and likely to break. Let us chat about big changes to std.os ahead of time and be intentional and precise about what exactly the goal is.

@andrewrk andrewrk closed this Sep 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants