Linux Work Culminating On A "READFILE" Syscall For Reading Small Files Efficiently

[d4ddi0]

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?



How would that even work...?

LoL. y'all been TROLLED! a single ioctl was replaced by open, read/write, close, with the advent of sysfs attrributes.

[d4ddi0]

If "small" is defined as under 4k, and it's handled in a backwards compatible way in libc (maybe make open() a noop, only actually "opening" if the file is large or opened for writing, and close() also potentially a noop), this could be an improvement for 90% of all file accesses.

[jacob]

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?

No aversion, but they shouldn't be introduced at whim. Ideally only really new concepts should have new syscalls, new operations on existing object types should be implemented using existing generic interfaces.

[JustinTurdeau]

Why does it need a new syscall?

Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?

Couldn't an ioctl call do it?

How would that even work...?

[jacob]

Why does it need a new syscall? Couldn't an ioctl call do it?

[phoronix]

Phoronix: Linux Work Culminating On A "READFILE" Syscall For Reading Small Files Efficiently

Stemming from recent kernel discussions over a hypothetical new system call for reading small files more efficiently, Greg Kroah-Hartman has been working on the readfile() system call and it's looking like it is taking shape well enough to premiere soon in a new mainline kernel release...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-READFILE-System-Call