All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jeff Garzik <jeff@garzik.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] splice support
Date: Wed, 29 Mar 2006 22:43:16 +0200	[thread overview]
Message-ID: <20060329204316.GC13476@suse.de> (raw)
In-Reply-To: <20060329204216.GB13476@suse.de>

On Wed, Mar 29 2006, Jens Axboe wrote:
> On Wed, Mar 29 2006, Linus Torvalds wrote:
> > 
> > 
> > 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 
> > paths).
> > 
> > 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.
> 
> Go ahead, as mentioned there are a few little extra fixes in the git
> repo. The remaining changes I had in mind don't require anything
> massive, so...

git://brick.kernel.dk/data/git/linux-2.6-block.git splice

is the url, just in case.

-- 
Jens Axboe


  reply	other threads:[~2006-03-29 20:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-29 12:28 [PATCH][RFC] splice support Jens Axboe
2006-03-29 12:30 ` Jens Axboe
2006-03-29 13:15 ` Jeff Garzik
2006-03-29 13:27   ` Jens Axboe
2006-03-29 21:49     ` Nathan Scott
2006-03-29 20:06   ` Linus Torvalds
2006-03-29 20:42     ` Jens Axboe
2006-03-29 20:43       ` Jens Axboe [this message]
2006-03-29 21:14         ` Linus Torvalds
2006-03-30  6:17           ` Jens Axboe
2006-03-29 22:37 ` Andrew Morton
2006-03-30  0:50   ` Linus Torvalds
2006-03-30  1:04     ` Jeff Garzik
2006-03-30  1:20       ` Andrew Morton
2006-03-30  6:18         ` Jens Axboe
2006-03-30  2:08     ` Andrew Morton
2006-03-30  3:44       ` Nick Piggin
2006-03-30  7:21       ` Jens Axboe
2006-03-30  7:30         ` Andrew Morton
2006-03-30  7:33           ` Jens Axboe
2006-03-30  8:02             ` Jan Engelhardt
2006-03-30  3:10     ` Nick Piggin
2006-03-30  7:16     ` Jens Axboe
2006-03-30  8:09     ` Jan Engelhardt
2006-03-30  7:45   ` Jens Axboe
2006-03-30  8:02     ` Andrew Morton
2006-03-30  8:10       ` Jens Axboe
2006-03-30  8:25         ` Nick Piggin
2006-03-30  8:27         ` Andrew Morton
2006-03-30  8:50           ` Nick Piggin
2006-03-30  8:51           ` Jens Axboe
2006-03-30  9:15             ` Jens Axboe
2006-03-30  9:40               ` Andrew Morton
2006-03-30  9:45                 ` Jens Axboe
2006-03-30  9:56                   ` Andrew Morton
2006-03-30 10:01                     ` Jens Axboe
2006-03-30  2:36 ` Nick Piggin
2006-03-30  7:00   ` Jens Axboe
2006-03-30  7:33     ` Nick Piggin
2006-03-30  8:54 ` KAMEZAWA Hiroyuki
2006-03-30 13:53   ` Jens Axboe
2006-03-30 14:05     ` KAMEZAWA Hiroyuki
2006-03-30 14:38       ` Jens Axboe
2006-03-30 14:55         ` KAMEZAWA Hiroyuki
  -- strict thread matches above, loose matches on Subject: below --
2005-12-19  9:16 Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060329204316.GC13476@suse.de \
    --to=axboe@suse.de \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.