Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • K kernel
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • redox-osredox-os
  • kernel
  • Merge requests
  • !194

Draft: Cross scheme links (scheme file forwarding)

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open 4lDO2 requested to merge 4lDO2/kernel:cross_scheme_links into master May 10, 2022
  • Overview 0
  • Commits 2
  • Pipelines 0
  • Changes 18

Implements cross scheme links, i.e. allows a scheme to return a file descriptor pertaining to different schemes than that scheme itself. This is implemented here both for SYS_OPEN and SYS_DUP.

This doubles the size of UserInner's done waitmap value, but since those are stored in a B-tree in the first place with a relatively small branching factor, it will most likely not have much of an effect besides memory use. An error code could otherwise get reserved for the kernel allowing it to look elsewhere for the new file descriptor if this turns out to be a performance problem.

Right now it uses a message to respond to SYS_OPEN and SYS_DUP syscalls, just like with SYS_FEVENT. While it would be possible to constrain the FD size from 63 bits to 62 bits, this feels to me like an unnecessary limitation e.g. given that schemes might use FDs directly for pointers. That would allow SchemeBlock and SchemeBlockMut to remain unchanged, but (1) I don't see how those schemes would benefit from FD forwarding, and (2) we might get better async scheme interfaces later with io_uring.

Forwarded file descriptors will be removed from the scheme handler's file descriptor table, so they will have to be duplicated first if the scheme handler really wants to keep them.

Blocked on syscall!69

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: cross_scheme_links