diff mbox series

[1/2] dax: hide block device code in #ifdef

Message ID 20170515134508.2713243-1-arnd@arndb.de
State New
Headers show
Series [1/2] dax: hide block device code in #ifdef | expand

Commit Message

Arnd Bergmann May 15, 2017, 1:44 p.m. UTC
We allow configurations with CONFIG_BLOCK=n and CONFIG_DAX=y, which now
results in a link error:

drivers/dax/super.c: In function 'bdev_dax_pgoff':
drivers/dax/super.c:50:26: error: implicit declaration of function 'get_start_sect'; did you mean 'get_task_cred'? [-Werror=implicit-function-declaration]

The two obvious ways to avoid the link error are to either add an #ifdef
around the code that was moved from fs/block_dev.c, or to disallow the
configuration. I could not see if there is or is not a reason to support
this combination of options, but in case there is, the #ifdef is the
safer choice.

Fixes: ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
 drivers/dax/super.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.9.0

Comments

Dan Williams May 15, 2017, 2:11 p.m. UTC | #1
On Mon, May 15, 2017 at 6:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> We allow configurations with CONFIG_BLOCK=n and CONFIG_DAX=y, which now

> results in a link error:

>

> drivers/dax/super.c: In function 'bdev_dax_pgoff':

> drivers/dax/super.c:50:26: error: implicit declaration of function 'get_start_sect'; did you mean 'get_task_cred'? [-Werror=implicit-function-declaration]

>

> The two obvious ways to avoid the link error are to either add an #ifdef

> around the code that was moved from fs/block_dev.c, or to disallow the

> configuration. I could not see if there is or is not a reason to support

> this combination of options, but in case there is, the #ifdef is the

> safer choice.

>

> Fixes: ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>


Yup, the same one I came up with:

https://patchwork.kernel.org/patch/9725513/

If you have a a pull request coming up soon you can add my Acked-by to
both of these patches, otherwise I'll send what I have along at the
end of the week.
Arnd Bergmann May 15, 2017, 2:20 p.m. UTC | #2
On Mon, May 15, 2017 at 4:11 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, May 15, 2017 at 6:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> We allow configurations with CONFIG_BLOCK=n and CONFIG_DAX=y, which now

>> results in a link error:

>>

>> drivers/dax/super.c: In function 'bdev_dax_pgoff':

>> drivers/dax/super.c:50:26: error: implicit declaration of function 'get_start_sect'; did you mean 'get_task_cred'? [-Werror=implicit-function-declaration]

>>

>> The two obvious ways to avoid the link error are to either add an #ifdef

>> around the code that was moved from fs/block_dev.c, or to disallow the

>> configuration. I could not see if there is or is not a reason to support

>> this combination of options, but in case there is, the #ifdef is the

>> safer choice.

>>

>> Fixes: ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")

>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>

> Yup, the same one I came up with:

>

> https://patchwork.kernel.org/patch/9725513/

>

> If you have a a pull request coming up soon you can add my Acked-by to

> both of these patches, otherwise I'll send what I have along at the

> end of the week.


I didn't plan to send a pull request, please use whatever you have.

      Arnd
Darrick J. Wong May 15, 2017, 3:50 p.m. UTC | #3
On Mon, May 15, 2017 at 04:20:09PM +0200, Arnd Bergmann wrote:
> On Mon, May 15, 2017 at 4:11 PM, Dan Williams <dan.j.williams@intel.com> wrote:

> > On Mon, May 15, 2017 at 6:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> >> We allow configurations with CONFIG_BLOCK=n and CONFIG_DAX=y, which now

> >> results in a link error:

> >>

> >> drivers/dax/super.c: In function 'bdev_dax_pgoff':

> >> drivers/dax/super.c:50:26: error: implicit declaration of function 'get_start_sect'; did you mean 'get_task_cred'? [-Werror=implicit-function-declaration]

> >>

> >> The two obvious ways to avoid the link error are to either add an #ifdef

> >> around the code that was moved from fs/block_dev.c, or to disallow the

> >> configuration. I could not see if there is or is not a reason to support

> >> this combination of options, but in case there is, the #ifdef is the

> >> safer choice.

> >>

> >> Fixes: ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")

> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

> >

> > Yup, the same one I came up with:

> >

> > https://patchwork.kernel.org/patch/9725513/

> >

> > If you have a a pull request coming up soon you can add my Acked-by to

> > both of these patches, otherwise I'll send what I have along at the

> > end of the week.

> 

> I didn't plan to send a pull request, please use whatever you have.


I don't mind pulling the (second) patch in via the xfs tree.

Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>


--D

> 

>       Arnd

> --

> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann May 16, 2017, 11:16 a.m. UTC | #4
On Mon, May 15, 2017 at 5:50 PM, Darrick J. Wong
<darrick.wong@oracle.com> wrote:
> On Mon, May 15, 2017 at 04:20:09PM +0200, Arnd Bergmann wrote:

>> On Mon, May 15, 2017 at 4:11 PM, Dan Williams <dan.j.williams@intel.com> wrote:

>> > On Mon, May 15, 2017 at 6:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> >> We allow configurations with CONFIG_BLOCK=n and CONFIG_DAX=y, which now

>> >> results in a link error:

>> >>

>> >> drivers/dax/super.c: In function 'bdev_dax_pgoff':

>> >> drivers/dax/super.c:50:26: error: implicit declaration of function 'get_start_sect'; did you mean 'get_task_cred'? [-Werror=implicit-function-declaration]

>> >>

>> >> The two obvious ways to avoid the link error are to either add an #ifdef

>> >> around the code that was moved from fs/block_dev.c, or to disallow the

>> >> configuration. I could not see if there is or is not a reason to support

>> >> this combination of options, but in case there is, the #ifdef is the

>> >> safer choice.

>> >>

>> >> Fixes: ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")

>> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>> >

>> > Yup, the same one I came up with:

>> >

>> > https://patchwork.kernel.org/patch/9725513/

>> >

>> > If you have a a pull request coming up soon you can add my Acked-by to

>> > both of these patches, otherwise I'll send what I have along at the

>> > end of the week.

>>

>> I didn't plan to send a pull request, please use whatever you have.

>

> I don't mind pulling the (second) patch in via the xfs tree.

>

> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>

>


I think Dan's "dax, xfs, ext4: compile out iomap-dax paths in the
FS_DAX=n case" handles this in a nicer way, so my patch 2/2 is not
needed any more.

      Arnd
diff mbox series

Patch

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index ebf43f531ada..6ed32aac8bbe 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -44,6 +44,7 @@  void dax_read_unlock(int id)
 }
 EXPORT_SYMBOL_GPL(dax_read_unlock);
 
+#ifdef CONFIG_BLOCK
 int bdev_dax_pgoff(struct block_device *bdev, sector_t sector, size_t size,
 		pgoff_t *pgoff)
 {
@@ -112,6 +113,7 @@  int __bdev_dax_supported(struct super_block *sb, int blocksize)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(__bdev_dax_supported);
+#endif
 
 /**
  * struct dax_device - anchor object for dax services