On Sat, Jul 04, 2020 at 04:02:46PM +0200, Greg Kroah-Hartman wrote:
Here is a tiny new syscall, readfile, that makes it simpler to read small/medium sized files all in one shot, no need to do open/read/close. This is especially helpful for tools that poke around in procfs or sysfs, making a little bit of a less system load than before, especially as syscall overheads go up over time due to various CPU bugs being addressed.
There are 4 patches in this series, the first 3 are against the kernel tree, adding the syscall logic, wiring up the syscall, and adding some tests for it.
The last patch is agains the man-pages project, adding a tiny man page to try to describe the new syscall.
General question, using this series as an illustration only:
At the risk of starting a flamewar, why is this needed? Is there a realistic usecase that would get significant benefit from this?
A lot of syscalls seem to get added that combine or refactor the functionality of existing syscalls without justifying why this is needed (or even wise). This case feels like a solution, not a primitive, so I wonder if the long-term ABI fragmentation is worth the benefit.
I ask because I'd like to get an idea of the policy on what is and is not considered a frivolous ABI extension.
(I'm sure a usecase must be in mind, but it isn't mentioned here. Certainly the time it takes top to dump the contents of /proc leaves something to be desired.)
Cheers ---Dave