RE: Is sendfile all that sexy?

[LA Walsh]

FYI -
	Another use sendfile(2) might be used for.  Suppose you were to generate
large amounts of data -- maybe kernel profiling data, audit data, whatever,
in the kernel.

	You want to pull that data out as fast as possible and write it to
a disk or network socket.  Normally, I think you'd do a "read/write" that
would xfer the data into user space, then write it back to the target
in system space.  With sendfile, it seems, one could write a dump-daemon
that used sendfile to dump the data directly out to a target file descriptor
w/o it going through user space.

	Just make sure the internal 'raw' data is massaged into the format
of a block device and voila!  A side benefit would be that data in the
kernel that is written to the block device would be 'queued' in the
block buffers and them being marked 'dirty' and needing to be written out.
The device driver marks the buffers as clean once they are pushed out
of a fd by doing a 'seek' to a new (later) position in the file -- whole
buffers
before that point are marked 'clean' and freed.

	Seems like this would have the benefit of reusing an existing
buffer management system for buffering while also using a single-copy
to get data to the target.

???
-l
--
L A Walsh                        | Trust Technology, Core Linux, SGI
[e-mail]                      | Voice/Vmail: [phone]