From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755913AbcK1Wv2 (ORCPT ); Mon, 28 Nov 2016 17:51:28 -0500 Received: from mga09.intel.com ([134.134.136.24]:61383 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755318AbcK1WvT (ORCPT ); Mon, 28 Nov 2016 17:51:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,565,1473145200"; d="scan'208";a="906490119" Date: Mon, 28 Nov 2016 15:51:16 -0700 From: Ross Zwisler To: Dan Williams Cc: Ross Zwisler , Arnd Bergmann , "Theodore Ts'o" , Alexander Viro , Matthew Wilcox , Jan Kara , Andrew Morton , Dave Chinner , linux-fsdevel , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] dax: try to avoid unused function warnings Message-ID: <20161128225116.GB1243@linux.intel.com> Mail-Followup-To: Ross Zwisler , Dan Williams , Arnd Bergmann , Theodore Ts'o , Alexander Viro , Matthew Wilcox , Jan Kara , Andrew Morton , Dave Chinner , linux-fsdevel , "linux-kernel@vger.kernel.org" References: <20161128211233.2446605-1-arnd@arndb.de> <20161128212400.GA16225@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 28, 2016 at 02:13:29PM -0800, Dan Williams wrote: > On Mon, Nov 28, 2016 at 1:24 PM, Ross Zwisler > 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 > > > > 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?