Discussion:
sendfile on various systems?
Georg Schwarz
2014-07-06 21:55:09 UTC
Permalink
On Linux, sendfile() looka like this:

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count)

On MacOS X it looks like this:

int
sendfile(int fd, int s, off_t offset, off_t *len, struct sf_hdtr *hdtr,
int flags)

what about other systems?

What's best practice of handling (probably Linux-originated) code that uses sendfile?
Should sendfile support best be disabled in systems other than Linux? (the code already has useful #ifdefs included)
--
Georg Schwarz http://home.pages.de/~schwarz/
***@freenet.de +49 176 91313874
Jean-Yves Migeon
2014-07-09 17:58:29 UTC
Permalink
Post by Georg Schwarz
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count)
int
sendfile(int fd, int s, off_t offset, off_t *len, struct sf_hdtr *hdtr,
int flags)
what about other systems?
What's best practice of handling (probably Linux-originated) code that uses sendfile?
Have a wrapper that implements sendfile() equivalent functionality
(usually mmap + write from userland). Somehow it blows, but the API
itself does already with non blocking sockets, so...
Post by Georg Schwarz
Should sendfile support best be disabled in systems other than Linux? (the code already has useful #ifdefs included)
I'd say no; FreeBSD has it. For NetBSD I don't know if it brings
anything useful besides being a wrapper around mmap + write (due to
UVM's page loaning, the only benefit being perhaps that the "loop" is
done in kernel).

Regarding prototype I'd say to keep glibc's one around; the original
syscall from Linux handled offset with a variable not big enough for
large files, and then they introduced sendfile64() to fix the limitation
(sigh).
--
Jean-Yves Migeon
Loading...