Why isn't there a sendfile64?
because nobody has implemented on -- arguably it's not needed; the
different between:
sendfile64(...)
and
while(blah){
sendfile( ... 1G or so ...)
}
probably won't be detectable anyhow. I see no reason why sendfile64
should be purely user-space (then again, I see no reason why not to
extend the kernel API as is, but last time I tested it is was busted
WRT signals so I would rather that be fixed before further
proliferation there).
--cw
On Tue, Feb 20, 2001 at 02:51:24PM +1300, Chris Wedgwood wrote:
> Why isn't there a sendfile64?
>
> because nobody has implemented on -- arguably it's not needed; the
> different between:
>
> sendfile64(...)
>
> and
>
> while(blah){
> sendfile( ... 1G or so ...)
> }
>
> probably won't be detectable anyhow. I see no reason why sendfile64
> should be purely user-space (then again, I see no reason why not to
> extend the kernel API as is, but last time I tested it is was busted
> WRT signals so I would rather that be fixed before further
> proliferation there).
Wrong. sendfile takes a pointer to off_t, not loff_t, so you cannot replace
sendfile64 with multiple sendfile's if offset is non-NULL from userland.
It simply won't work properly on big files (no matter what size you transfer
at a time).
Jakub