1 files changed, 0 insertions, 316 deletions
diff --git a/lib/libc/sys/sendfile.2 b/lib/libc/sys/sendfile.2
deleted file mode 100644
index d9f8cab..0000000
--- a/lib/libc/sys/sendfile.2
+++ /dev/null
@@ -1,316 +0,0 @@
-.\" Copyright (c) 2003, David G. Lawrence
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice unmodified, this list of conditions, and the following
-.\"    disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\" $FreeBSD$
-.\"
-.Dd January 7, 2010
-.Dt SENDFILE 2
-.Os
-.Sh NAME
-.Nm sendfile
-.Nd send a file to a socket
-.Sh LIBRARY
-.Lb libc
-.Sh SYNOPSIS
-.In sys/types.h
-.In sys/socket.h
-.In sys/uio.h
-.Ft int
-.Fo sendfile
-.Fa "int fd" "int s" "off_t offset" "size_t nbytes"
-.Fa "struct sf_hdtr *hdtr" "off_t *sbytes" "int flags"
-.Fc
-.Sh DESCRIPTION
-The
-.Fn sendfile
-system call
-sends a regular file specified by descriptor
-.Fa fd
-out a stream socket specified by descriptor
-.Fa s .
-.Pp
-The
-.Fa offset
-argument specifies where to begin in the file.
-Should
-.Fa offset
-fall beyond the end of file, the system will return
-success and report 0 bytes sent as described below.
-The
-.Fa nbytes
-argument specifies how many bytes of the file should be sent, with 0 having the special
-meaning of send until the end of file has been reached.
-.Pp
-An optional header and/or trailer can be sent before and after the file data by specifying
-a pointer to a
-.Vt "struct sf_hdtr" ,
-which has the following structure:
-.Pp
-.Bd -literal -offset indent -compact
-struct sf_hdtr {
-	struct iovec *headers;	/* pointer to header iovecs */
-	int hdr_cnt;		/* number of header iovecs */
-	struct iovec *trailers;	/* pointer to trailer iovecs */
-	int trl_cnt;		/* number of trailer iovecs */
-};
-.Ed
-.Pp
-The
-.Fa headers
-and
-.Fa trailers
-pointers, if
-.Pf non- Dv NULL ,
-point to arrays of
-.Vt "struct iovec"
-structures.
-See the
-.Fn writev
-system call for information on the iovec structure.
-The number of iovecs in these
-arrays is specified by
-.Fa hdr_cnt
-and
-.Fa trl_cnt .
-.Pp
-If
-.Pf non- Dv NULL ,
-the system will write the total number of bytes sent on the socket to the
-variable pointed to by
-.Fa sbytes .
-.Pp
-The
-.Fa flags
-argument is a bitmap of these values:
-.Bl -item -offset indent 
-.It
-.Dv SF_NODISKIO .
-This flag causes any
-.Fn sendfile
-call which would block on disk I/O to instead
-return
-.Er EBUSY .
-Busy servers may benefit by transferring requests that would
-block to a separate I/O worker thread.
-.It
-.Dv SF_MNOWAIT .
-Do not wait for some kernel resource to become available,
-in particular,
-.Vt mbuf
-and
-.Vt sf_buf .
-The flag does not make the
-.Fn sendfile
-syscall truly non-blocking, since other resources are still allocated
-in a blocking fashion.
-.It
-.Dv SF_SYNC .
-.Nm
-sleeps until the network stack no longer references the VM pages
-of the file, making subsequent modifications to it safe.
-Please note that this is not a guarantee that the data has actually
-been sent.
-.El
-.Pp
-When using a socket marked for non-blocking I/O,
-.Fn sendfile
-may send fewer bytes than requested.
-In this case, the number of bytes successfully
-written is returned in
-.Fa *sbytes
-(if specified),
-and the error
-.Er EAGAIN
-is returned.
-.Sh IMPLEMENTATION NOTES
-The
-.Fx
-implementation of
-.Fn sendfile
-is "zero-copy", meaning that it has been optimized so that copying of the file data is avoided.
-.Sh TUNING
-On some architectures, this system call internally uses a special
-.Fn sendfile
-buffer
-.Pq Vt "struct sf_buf"
-to handle sending file data to the client.
-If the sending socket is
-blocking, and there are not enough
-.Fn sendfile
-buffers available,
-.Fn sendfile
-will block and report a state of
-.Dq Li sfbufa .
-If the sending socket is non-blocking and there are not enough
-.Fn sendfile
-buffers available, the call will block and wait for the
-necessary buffers to become available before finishing the call.
-.Pp
-The number of
-.Vt sf_buf Ns 's
-allocated should be proportional to the number of nmbclusters used to
-send data to a client via
-.Fn sendfile .
-Tune accordingly to avoid blocking!
-Busy installations that make extensive use of
-.Fn sendfile
-may want to increase these values to be inline with their
-.Va kern.ipc.nmbclusters
-(see
-.Xr tuning 7
-for details).
-.Pp
-The number of
-.Fn sendfile
-buffers available is determined at boot time by either the
-.Va kern.ipc.nsfbufs
-.Xr loader.conf 5
-variable or the
-.Dv NSFBUFS
-kernel configuration tunable.
-The number of
-.Fn sendfile
-buffers scales with
-.Va kern.maxusers .
-The
-.Va kern.ipc.nsfbufsused
-and
-.Va kern.ipc.nsfbufspeak
-read-only
-.Xr sysctl 8
-variables show current and peak
-.Fn sendfile
-buffers usage respectively.
-These values may also be viewed through
-.Nm netstat Fl m .
-.Pp
-If a value of zero is reported for
-.Va kern.ipc.nsfbufs ,
-your architecture does not need to use
-.Fn sendfile
-buffers because their task can be efficiently performed
-by the generic virtual memory structures.
-.Sh RETURN VALUES
-.Rv -std sendfile
-.Sh ERRORS
-.Bl -tag -width Er
-.It Bq Er EAGAIN
-The socket is marked for non-blocking I/O and not all data was sent due to
-the socket buffer being filled.
-If specified, the number of bytes successfully sent will be returned in
-.Fa *sbytes .
-.It Bq Er EBADF
-The
-.Fa fd
-argument
-is not a valid file descriptor.
-.It Bq Er EBADF
-The
-.Fa s
-argument
-is not a valid socket descriptor.
-.It Bq Er EBUSY
-Completing the entire transfer would have required disk I/O, so
-it was aborted.
-Partial data may have been sent.
-(This error can only occur when
-.Dv SF_NODISKIO
-is specified.)
-.It Bq Er EFAULT
-An invalid address was specified for an argument.
-.It Bq Er EINTR
-A signal interrupted
-.Fn sendfile
-before it could be completed.
-If specified, the number
-of bytes successfully sent will be returned in
-.Fa *sbytes .
-.It Bq Er EINVAL
-The
-.Fa fd
-argument
-is not a regular file.
-.It Bq Er EINVAL
-The
-.Fa s
-argument
-is not a SOCK_STREAM type socket.
-.It Bq Er EINVAL
-The
-.Fa offset
-argument
-is negative.
-.It Bq Er EIO
-An error occurred while reading from
-.Fa fd .
-.It Bq Er ENOTCONN
-The
-.Fa s
-argument
-points to an unconnected socket.
-.It Bq Er ENOTSOCK
-The
-.Fa s
-argument
-is not a socket.
-.It Bq Er EOPNOTSUPP
-The file system for descriptor
-.Fa fd
-does not support
-.Fn sendfile .
-.It Bq Er EPIPE
-The socket peer has closed the connection.
-.El
-.Sh SEE ALSO
-.Xr netstat 1 ,
-.Xr open 2 ,
-.Xr send 2 ,
-.Xr socket 2 ,
-.Xr writev 2 ,
-.Xr tuning 7
-.Rs
-.%A K. Elmeleegy
-.%A A. Chanda
-.%A A. L. Cox
-.%A W. Zwaenepoel
-.%T A Portable Kernel Abstraction for Low-Overhead Ephemeral Mapping Management
-.%J The Proceedings of the 2005 USENIX Annual Technical Conference
-.%P pp 223-236
-.%D 2005
-.Re
-.Sh HISTORY
-The
-.Fn sendfile
-system call
-first appeared in
-.Fx 3.0 .
-This manual page first appeared in
-.Fx 3.1 .
-.Sh AUTHORS
-The
-.Fn sendfile
-system call
-and this manual page were written by
-.An David G. Lawrence Aq dg@dglawrence.com .