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