If your xfs[cvs] resembles the xfs source in 2.5.50-mm1, then it looks
to me like fs/xfs/linux has a .sendfile = linvfs_sendfile in xfs_file.c
(which assures the loop driver it can loop this file for reading), but
lacks a .vop_ioctl = xfs_sendfile (and its extern) in xfs_vnodeops.c.
But I've not delved into XFS, for all I know that code may not be ready
to use yet: Christoph can say. And to get further with the 2.5.47 loop,
you'll also need this patch (in 2.5.48):
--- 2.5.47/drivers/block/loop.c Mon Nov 11 12:34:14 2002
+++ linux/drivers/block/loop.c Mon Nov 11 15:44:33 2002
@@ -304,21 +304,16 @@
{
struct lo_read_data cookie;
struct file *file;
- int error;
+ int retval;
cookie.lo = lo;
cookie.data = kmap(bvec->bv_page) + bvec->bv_offset;
cookie.bsize = bsize;
-
- /* umm, what does this lock actually try to protect? */
- spin_lock_irq(&lo->lo_lock);
file = lo->lo_backing_file;
- spin_unlock_irq(&lo->lo_lock);
-
- error = file->f_op->sendfile(file, &pos, bvec->bv_len,
+ retval = file->f_op->sendfile(file, &pos, bvec->bv_len,
lo_read_actor, &cookie);
kunmap(bvec->bv_page);
- return error;
+ return (retval < 0)? retval: 0;
}
static int
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/