How useful should copy_file_range() be?
How useful should copy_file_range() be?
Posted Feb 19, 2021 20:29 UTC (Fri) by the8472 (guest, #144969)In reply to: How useful should copy_file_range() be? by Deewiant
Parent article: How useful should copy_file_range() be?
You're looking at the linux implementation for io::copy which can copy arbitrary readers to writers but specializes to various syscalls when types wrapping file descriptors of unknown type are passed, hence the complexity.
There also is fs::copy which shares some code but has fewer cases to cover and does fewer checks before invoking copy_file_range since it's only meant to copy entire regular files.
The relevant parts are here and here
. Note that it doesn't use stat information to decide what to do in thefs::copy case, it just tries copy_file_range and then falls back in various cases, including 0 byte reads.
Posted Jul 10, 2021 12:57 UTC (Sat)
by jaykrell (guest, #153190)
[Link] (3 responses)
Not everything is a file!
In fact, most things are not a file.
Posted Jul 10, 2021 13:54 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Jul 10, 2021 21:48 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jul 10, 2021 23:16 UTC (Sat)
by flussence (guest, #85566)
[Link]
You're being facetious, but it's occasionally very useful to be able to do things like check which port a monitor is plugged in on or framedump the console on a server using only ssh.
How useful should copy_file_range() be?
This data should be retrieved through strongly typed special purpose function calls.
Or at least, perhaps, allow open, for a hierarchical namespace, but not read, and reveal all information via ioctl.
Is the screen a file?
Is the keyboard a file?
Are sockets files? They have read/write, but how about seek and mmap?
How useful should copy_file_range() be?
How useful should copy_file_range() be?
Windows NT tried that. It failed miserably.
How useful should copy_file_range() be?
>Is the keyboard a file?
