[lkml]   [2006]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][RFC] splice support

    On Wed, 29 Mar 2006, Jeff Garzik wrote:
    > 1) What are the consequences of doing
    > if (f_op->splice_write)
    > f_op->splice_write(...);
    > else
    > generic_file_splice_write(...);
    > to cause sys_splice() to default to supported?

    I'd actually much prefer a number of filesystems just adding he
    "generic_file_splice_write()" thing. If it works for them (and it usually
    will), it's a one-liner. And it won't do wrong things on filesystems that
    have special rules (inode re-validate for networked filesystems etc).

    > 2) Do you really have to test f_op itself for NULL? Is that a stealth
    > closed-file check or something? I would be surprised if f_op was ever really
    > NULL.

    Hmm.. I agree that f_op probably should never be NULL (a struct file with
    a NULL f_op is pretty useless), but it is a test that we historically have
    had. So it's probably best to keep for consistency, and if somebody wants
    to, they can clean up all the other tests too (in the read/write/lseek

    I'm inclined to apply this patch (well, I'd like the fixed one). The whole
    splice() thing has been rolling around in my head for years, and the pipe
    support infrastructure for it has been around for over a year now in
    preparation for this.

    And the patch actually looks pretty clean to me.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.020 / U:2.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site