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
