Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, 30 Mar 2015 18:40:16 -0400 Milosz Tanski [off-list ref] wrote:

On Mon, Mar 30, 2015 at 2:54 PM, Andrew Morton
[off-list ref] wrote:

quoted

On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig [off-list ref] wrote:

quoted

On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:

quoted

mm...  I don't think we should be adding placeholders to the kernel API
to support code which hasn't been written, tested, reviewed, merged,
etc.  It's possible none of this will ever happen and we end up with a
syscall nobody needs or uses.  Plus it's always possible that during
this development we decide the pwrite2() interface needs alteration but
it's too late.

What would be the downside of deferring pwrite2() until it's all
implemented?

It _is_ implemented.  I just decided to submit it separately as Miklos
already has to deal with enough bikeshedding for his feature that I
don't want to put the burden of dealing with the BS for the one I wrote
on him.

afacit the only difference between this pwritev2() and the existing
pwritev() is that pwritev2() interprets pos==-1 as "current position",
which duplicates writev()?

Unless I've missed something, there's no point in merging this
pwritev2() and it would be better to separate this syscall out into a
pwritev2() patchset which can be considered and merged separately.  For
the reasons described above.

At the LSF/MM session, the agreement form the active participants
(James Bottomley, Ted Tso, Christoph, and I forget the last guy's
name) that we should ship both syscalls in the first patch.

I was over in the mm session and probably wouldn't have objected either
because because you can't sit down, think, carefully inspect code and
evaluate arguments in such a context.

I've explained my reasoning.  If there's something wrong with that
reasoning or if there are contradictory reasons which I'm not aware of
then let's hear them!