Re: Emulation of sendfile().
On 16/02/2014 12:33, Mats Erik Andersson wrote:
> But this raises a new question: Will present or future versions
> of eglibc, with the architecture kfreebsd-any, expose a functional
> library call
>
> ssize_t sendfile (int, int, off_t, size_t)
>
> for general use? I.e., will the stub ever be replaced?
This prototype is declared in <sys/sendfile.h> which is a kernel-independant
header.
I think it is a bug to declare prototypes for Linux-specific syscalls in
kernel-independant headers. However this comes from upstream and it is unlikely
they will want to change it.
Another possibility would be implementing a sendfile() that is compatible with
Linux semantics in userland, and merging that in our port of glibc.
But note that either of these possibilities is off my scope. It'd have to be
discussed with the glibc maintainers.
If you can write a Linux-compatible sendfile() which uses BSD-ish SYS_sendfile
as backend, I guess they'll have no problem exporting a new symbol in glibc?
After all, it's glibc who claims to provide it (via <sys/sendfile.h>).
> Otherwise
> each and every software will need substantial patching on kFreeBSD
> to achieve better throughput, since it would need to link to
> freebsd-glue and rely on the FreeBSD signature of sendfile(),
> or to be rewritten using bsd_sendfile.
You don't have to rewrite anything to use bsd_sendfile(). If you're trying
to build BSD software, you can use freebsd-glue if you think this will ease your
porting work.
For software that expects the Linux version of sendfile(), a different solution
is required, and freebsd-glue has nothing to do with that.
--
Robert Millan
Reply to: