O_TMPFILE extensions? better new syscalls for temporary files #44
Replies: 2 comments
-
tmpfd_create would have a signature like tmpfd_create(int dirfd, const char *name, unsigned int flags); where "name" has a memfd like behaviour just for debugging. dirfd should be a valid fd refering to a directory or AT_FDCWD. by default tmpfd cannot be made visible in the filesystem unless a "flag" is passed, if this flag is not set it might behave like memfd if the target filesystem is tmpfs or something similar. by default O_CLOEXEC is set, if not desirable TMPFD_INHERIT or using fcntl is needed to undo that.. further ideas welcome |
Beta Was this translation helpful? Give feedback.
-
If the system call doesn't offer new functionality then this is unlikely to fly upstream given that we already have a way to create tmpfiles. The bit that is interesting is really just that we're able to link/replace it into the filesystem. Whether that's done through renamat2() or linkat() isn't that important imho. |
Beta Was this translation helpful? Give feedback.
-
It is my belief that new open() flags or additions for dealing with temporary files do more harm than good and that a tmpfd_create syscall +tmpfd_materialze() or renameat2() + tmpfd specific flags to make them visible in the filesystem, with sane well defined semantics is a nicer, easier to support interface for userspace components.
Beta Was this translation helpful? Give feedback.
All reactions