copy_file_range linux syscall #6010
Conversation
daurnimator
added
the
standard library
| // TODO take advantage of copy_file_range OS APIs | ||
| var buf: [8 * 4096]u8 = undefined; | ||
| const adjusted_count = math.min(buf.len, len); | ||
| const amt_read = try in.pread(buf[0..adjusted_count], in_offset); |
There was a problem hiding this comment.
I think the fallback path should remain here for systems that don't support os.copy_file_range (rather than being moved to os.zig)
There was a problem hiding this comment.
os.zig should be about what the OS supports: papering over differences and making abstractions for files should be in file.zig.
There was a problem hiding this comment.
os.zig is to be renamed to posix.zig: #5019
it is its job to paper over differences in that layer. there's already precedent for this with all the other read/write functions. Even if the proposal you are making were to be accepted it would not apply to this PR, it would be a separate proposal.
There was a problem hiding this comment.
copy_file_range isn't posix either; it's a linux-specific syscall.
normal reading/writing does have standard posix interfaces.
There was a problem hiding this comment.
zig's posix api layer is bespoke. It's not strictly conforming to posix. It cannot be; posix is specific to C. So it's "zig flavored posix" and whatever code has the same logical abstraction level as other posix functions go there. copy_file_range is clearly in that same layer.
|
Take advantage of
copy_file_rangesyscall inFile.copyRange.