tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [GSoC 2026] - Implementation of sendfile(2) syscall



Hi,

On Fri, 6 Mar 2026 13:20:49 +0100, Reinoud**Zandijk wrote:

Well, looking at sendfile(2), i wonder what the difference is between
sendfile(2) and copy_file_range(2) that seems more generic; is it that
sendfile can also copy non-seekable

Exactly, the copy_file_range(2) only works with regular files, but offers
more flexibility for that case.

The sendfile(2) can be used with a broader set of file types:
- Regular File -> Regular File
- Regular File -> Socket
- Regular File -> Pipe
- Socket -> Pipe (according to man page, this should desugars to a splice in the Linux implementation)

Can't sendfile(2) be implemented
then as a copy_file_range(2) when they are both regular files?

There should not be any problem with using copy_file_range(2) when both
sendfile(2) file descriptors are regular files.
Both syscalls are implemented in a similar way (with reads & writes),
but I noticed the Compat Linux emulation for copy_file_range(2)
uses a 8192 byte buffer, while this one for sendfile(2) is using MAXBSIZE.
I wonder if there is a specific reason for the smaller buffer size,
as it may impact performance.

It would be nice if file systems could get a VOP call on this; some FSes can
then internally just copy its administration or references without even
needing to load from and save to disc. FSes then can by defaukt bail out or
decide its not feasable if say its not possible for whatever reason like it
crosses mountpoints and the generic data read/write copy-in-the-kernel code
could then take over.

That makes sense to me, I believe Linux does something similar in its
sendfile/splice implementation.
That said, for the purpose of emulation, I believe the read/write loops
in the kernel are sufficient, though the VOP would provide a nice optimization.

This seems like a potential GSoC project, would it be a|reasonable| scope
for someone still new to kernel development?

Thank you,
Henrique Brito



Home | Main Index | Thread Index | Old Index