[lsb-discuss] sendfile() summary

[Jeff Licquia]

We've talked about sendfile() as a potential candidate for the LSB.  I'm 
going to summarize what we seem to know, and propose that we go ahead 
and include it in LSB 3.2.  If I'm wrong, or if there are other 
objections, now is the time to speak up.

sendfile() is supported in Linux for as far back as we care about.  The 
ABI has been mostly stable, and its purpose is well-known.  It is used 
in a fair number of projects, and is considered important for network 
performance.

It does have some issues, however:

  - Its ABI changed slightly between 2.4 and 2.6 kernels.  The call 
semantics did not change, but the constraints on the parameters did; the 
input and output file descriptors must now be of certain types in 2.6. 
However, since anyone following the 2.6 restrictions will work on 2.4, 
this shouldn't preclude us from settling on the 2.6 ABI (even if we 
assume that 2.4 issues are still relevant).

  - There is some uncertainty about whether sendfile() works with all 
Linux filesystems.  The man page only specifies that the input file 
descriptor be on a filesystem that supports mmap(), but there are rumors 
of other restrictions.  It would be good to see some documentation of 
those additional restrictions.

  - sendfile() is implemented differently on other UNIXes.  There does 
not seem to be a move to rationalize the different ABIs, and it's very 
likely that the Linux ABI would become the "single ABI" should such an 
effort get going, judging by how apps handle the differences now. 
(Mozilla, for example, gets around the problem by making other OS 
sendfile() implementations look like Linux.)  But there is a risk, 
however small, that we might want to change the interface in the future.

Based on these findings, I propose that sendfile() should go in.  Are 
there objections or corrections?