Чем в линуксах(актуальных версиях ядра) отличаются друг от друга системные вызовы splice и sendfile?

Если так, почему б не сделать один системный вызов

splice появился позже sendfile. А userspace API в линуксе принято не ломать.

который бы и к пайпам, и к сокетам, и к обычным файловым дескрипторам был применим?

Ограничения по видам fd в splice - технического характера, когда-нибудь допилят это, если ещё не.

Например если я свою ОС вздумаю написать, какие системные вызовы лучше делать?

Какие считаешь нужным, твоя же ОС.

В линуксе аргументами splice() могут быть любые fd.

Это вроде про sendfile(), начиная с версии 2.6.33.

Оба вызова не являются вызовами общего назначения. Они оптимизации частных случаев. sendfile() для отправки файла по сети для каких-нибудь серверов. Потом подобное понадобилось для pipe, но sendfile() отображает источник на память, что не будет работать с pipe. Для всех возможных случаев такой API особо не нужен, а лишнее в ядре городить тоже не очень (разные типы файлов могут требовать разных оптимальных реализаций и обработки ошибок).

Есть вообще какие-то правила, которым надо следовать в плане системных вызовов?

Те, которые имеют смысл для конкретной реализации и достижения конкретных целей. Какие-то вещи устоявшиеся (open(), close() и т.д.), а какие-то могут быть нужны (или вообще возможными) из-за структурных особенностей. В ядро что-то идёт, если его нельзя реализовать без участия ядра либо же это даст значительные преимущества (потоки, например, были в userspace, но реализация оставляла желать лучшего из-за своих ограничений).

ОК, если я хочу создать свой аналог dd но быстрее(чтоб более напрямую было) то что мне лучше использовать, sendfile или splice?

Сделай бенчмарк.

splice же требует pipe в одном из дескрипторов, так что не сработает в большенстве случаев и sendfile выходит универсальнее. А если он упадёт с ошибкой, то можно копировать вручную (можно два mmap, posix_fadvice и потом memcpy). А так анонимус дело говорит, надо проверять и сравнивать результаты.

where one of the descriptors must refer to a pipe.

Йопт.

У vmsplice() схоже. Я прозреваю, что сделано это было ради zero copy IPC.

pipe на самом деле является буфером, находящимся в пространстве ядра. При пересылке из произвольного дескриптора в произвольный в любом случае потребовался бы механизм буферизации, решили воспользоваться готовым. При этом через обычный fcntl мы можем настраивать размер этого буфера, не плодятся новые сисколлы. Функции, которые есть, на самом деле просто обёртки над этим буфером: передать кусок памяти в буфер, скопировать один буфер в другой, записать/прочитать в буфер из fd. То есть это всё, что мы можем делать с обычным read/write и char buf[], но запихнуто в ядро и вынесено в такой лаконичный интерфейс.

splice же требует pipe в одном из дескрипторов, так что не сработает в большенстве случаев

Вообще-то, типичный сценарий использования splice - это копирование из fd1 во пайп, а затем копирование из пайпа в fd2, блоками по 64К так как больше в пайп не влезет. Поэтому все наоборот, это splice более универсален, так как у sendfile источник обязательно должен быть файлом

Вообще-то, типичный сценарий использования splice - это копирование из fd1 во пайп, а затем копирование из пайпа в fd2

Я его на самом деле не использовал и ориентировался по ману, в котором такой пример был бы полезен. Теперь буду знать, спасибо.

блоками по 64К так как больше в пайп не влезет.

До 1 МиБ влазит при расширении и можно увеличивать:

$ cat /proc/sys/fs/pipe-max-size
1048576