Re: [PATCH] dax: try to avoid unused function warnings

From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>, "Theodore Ts'o" <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@linux.intel.com>, Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Chinner <dchinner@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dax: try to avoid unused function warnings
Date: Mon, 28 Nov 2016 15:51:16 -0700	[thread overview]
Message-ID: <20161128225116.GB1243@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4iHKqYcq2OZZynUzMe8aF4JiKCUZa2JnERGC9MC7aY8Lg@mail.gmail.com>

On Mon, Nov 28, 2016 at 02:13:29PM -0800, Dan Williams wrote:
> On Mon, Nov 28, 2016 at 1:24 PM, Ross Zwisler
> <ross.zwisler@linux.intel.com> wrote:
> > On Mon, Nov 28, 2016 at 10:12:17PM +0100, Arnd Bergmann wrote:
> >> Without the get_block based I/O, we get warnings when CONFIG_FS_IOMAP
> >> is disabled:
> >>
> >> fs/dax.c:736:12: error: ‘dax_insert_mapping’ defined but not used [-Werror=unused-function]
> >> fs/dax.c:512:12: error: ‘copy_user_dax’ defined but not used [-Werror=unused-function]
> >> fs/dax.c:490:12: error: ‘dax_load_hole’ defined but not used [-Werror=unused-function]
> >> fs/dax.c:294:14: error: ‘grab_mapping_entry’ defined but not used [-Werror=unused-function]
> >>
> >> This patch blindly marks those as __maybe_unused, which avoids the warnings.
> >> However, I suspect that there is actually more code in this file that should
> >> not be provided without CONFIG_FS_IOMAP even though we don't get a warning
> >> for it, and that we actually want a different rework, so please treat this
> >> as a bug report. I have applied the patch locally in my randconfig build
> >> setup to avoid seeing the warnings.
> >>
> >> Fixes: 5ac65736f740 ("dax: rip out get_block based IO support")
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Thanks for the report.  I think the right way to deal with this is to just
> > select FS_IOMAP when we pull in the DAX code.  I sent out a patch last week
> > that does this:
> >
> > https://lkml.org/lkml/2016/11/23/591
> 
> It seems awkward for both filesystems and the FS_DAX core to be
> selecting FS_IOMAP.  In the end FS_DAX and FS_IOMAP are both libraries
> of functionality that a filesystem can optionally use.  I think the
> longer term FS_DAX stops being an independent user visible setting and
> is instead selected by filesystems that want DAX.

This doesn't make sense to me.  DAX is a user-selectable option that changes
behavior (at the user's request), but FS_IOMAP is a library of functionality
that is required for XFS and for DAX.

The filesystems can all work fine without DAX (hence the user option), but DAX
and XFS at least require FS_IOMAP to behave correctly.

If you made DAX a FS selectable option instead of a user selectable one, when
would a FS know it needs to include DAX support?