From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752895AbbHEPTK (ORCPT <rfc822;w@1wt.eu>);
	Wed, 5 Aug 2015 11:19:10 -0400
Received: from mga09.intel.com ([134.134.136.24]:65339 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752438AbbHEPTG (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Aug 2015 11:19:06 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.15,618,1432623600"; 
   d="scan'208";a="742751692"
Date: Wed, 5 Aug 2015 11:19:04 -0400
From: Matthew Wilcox <willy@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
Subject: Re: [PATCH 04/11] ext4: Add ext4_get_block_dax()
Message-ID: <20150805151904.GD13681@linux.intel.com>
References: <1438718285-21168-1-git-send-email-matthew.r.wilcox@intel.com>
 <1438718285-21168-5-git-send-email-matthew.r.wilcox@intel.com>
 <20150805020357.GA3902@dastard>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150805020357.GA3902@dastard>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 05, 2015 at 12:03:57PM +1000, Dave Chinner wrote:
> On Tue, Aug 04, 2015 at 03:57:58PM -0400, Matthew Wilcox wrote:
> > From: Matthew Wilcox <willy@linux.intel.com>
> > 
> > DAX wants different semantics from any currently-existing ext4
> > get_block callback.  Unlike ext4_get_block_write(), it needs to honour
> > the 'create' flag, and unlike ext4_get_block(), it needs to be able
> > to return unwritten extents.  So introduce a new ext4_get_block_dax()
> > which has those semantics.  We could also change ext4_get_block_write()
> > to honour the 'create' flag, but that might have consequences on other
> > users that I do not currently understand.
> > 
> > Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> 
> Doesn't this make the first patch in the series redundant?

As I explained in the cover letter, patch 1 already went to Ted.  It might
be on its way in, and it might not.  Rather than sending a patch that
applies to current mainline and forcing someone to fix up a conflict
later, better to resend the patch as part of this series, and our tools
will do the right thing no matter which order patches go into Linus' tree.