.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "SKEL_WRITE" "" "06 October 2005" "" ""

.SH NAME
skel_write \- 
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
ssize_t skel_write  (struct file * \fIfile\fB, const char * \fIbuffer\fB, size_t \fIcount\fB, loff_t * \fIppos\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIfile\fB\fR
-- undescribed --
.TP
\fB\fIbuffer\fB\fR
-- undescribed --
.TP
\fB\fIcount\fB\fR
-- undescribed --
.TP
\fB\fIppos\fB\fR
-- undescribed --
.SH "DESCRIPTION"
.PP
.PP
A device driver has to decide how to report I/O errors back to the
user.  The safest course is to wait for the transfer to finish before
returning so that any errors will be reported reliably.  \fBskel_read\fR
works like this.  But waiting for I/O is slow, so many drivers only
check for errors during I/O initiation and do not report problems
that occur during the actual transfer.  That's what we will do here.
.PP
A driver concerned with maximum I/O throughput would use double-
.SH "BUFFERING"
.PP
Two urbs would be devoted to write transfers, so that
one urb could always be active while the other was waiting for the
user to send more data.