All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Namjae Jeon <namjae.jeon@samsung.com>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: linux-next: build warning after merge of the vfs tree
Date: Tue, 10 Mar 2020 00:17:39 +0100	[thread overview]
Message-ID: <20200309231739.2w45cleifsmwbfd6@pali> (raw)
In-Reply-To: <20200310095918.3ea6432f@canb.auug.org.au>

On Tuesday 10 March 2020 09:59:18 Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> warning: same module names found:
>   fs/exfat/exfat.ko
>   drivers/staging/exfat/exfat.ko
> 
> Introduced by commit
> 
>   b9d1e2e6265f ("exfat: add Kconfig and Makefile")
> 
> and not fixed by commit
> 
>   1a3c0509ce83 ("staging: exfat: make staging/exfat and fs/exfat mutually exclusive")

Hello Stephen!

exfat.ko from fs/exfat subdirectory is a rewrite/cleanup of staging
exfat driver. It means that fs/exfat replaces staging/exfat and so after
fs/exfat is merged, the old staging/exfat code is not needed anymore.

Therefore I think that instead of hacking Kconfig/Makefile files to
define mutually exclusivity, it is better to remove staging/exfat code.

Removal of old staging code should be easy and should fix this problem.

Any objections? Or other ideas?

  reply	other threads:[~2020-03-09 23:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 22:59 linux-next: build warning after merge of the vfs tree Stephen Rothwell
2020-03-09 23:17 ` Pali Rohár [this message]
2020-03-09 23:36   ` Namjae Jeon
2020-03-10 10:32     ` 'Greg Kroah-Hartman'
2020-03-10 10:54     ` [PATCH] staging: exfat: remove staging version of exfat filesystem Greg Kroah-Hartman
2020-03-10 10:54       ` Greg Kroah-Hartman
2020-03-10 11:18       ` Valdis Klētnieks
2020-03-10 11:18         ` Valdis Klētnieks
2020-03-11 22:47       ` Pali Rohár
2020-03-11 22:47         ` Pali Rohár
  -- strict thread matches above, loose matches on Subject: below --
2021-04-12 11:47 linux-next: build warning after merge of the vfs tree Stephen Rothwell
2021-04-12 13:07 ` Miklos Szeredi
2021-04-15 21:19   ` Al Viro
2021-01-06 23:15 Stephen Rothwell
2021-01-07  0:37 ` Gao Xiang
2021-01-07  0:40 ` Al Viro
2020-09-24  1:40 Stephen Rothwell
2020-09-24  2:00 ` Al Viro
2020-06-16  0:21 Stephen Rothwell
2019-02-03 22:33 Stephen Rothwell
2019-03-18  0:00 ` Stephen Rothwell
2019-03-25 23:05   ` Stephen Rothwell
2018-09-06  0:02 Stephen Rothwell
2018-09-07  8:57 ` David Howells
2018-06-19  1:53 Stephen Rothwell
2018-06-19  1:29 Stephen Rothwell
2018-05-17  0:39 Stephen Rothwell
2018-05-17  6:41 ` Christoph Hellwig
2018-05-14  0:56 Stephen Rothwell
2017-09-07 23:25 Stephen Rothwell
2017-09-08  5:53 ` Dmitry V. Levin
2017-09-14  1:51 ` Stephen Rothwell
2017-07-03  0:53 Stephen Rothwell
2017-07-09 23:34 ` Stephen Rothwell
2015-04-13  4:00 Stephen Rothwell
2012-10-12  5:06 Stephen Rothwell
2012-09-25  1:52 Stephen Rothwell
2012-01-05  6:35 Stephen Rothwell
2012-01-05  8:06 ` Al Viro
2012-01-05  8:14   ` Al Viro
2012-01-05 11:34     ` Jan Kara
2012-01-05  8:14   ` Stephen Rothwell
2012-01-05  8:19     ` Al Viro
2011-07-18  5:04 Stephen Rothwell
2011-07-18  5:17 ` Al Viro
2011-07-18  5:20   ` Al Viro
2010-07-05  0:01 Stephen Rothwell
2010-07-05  8:10 ` Al Viro
2010-07-05 10:44   ` Stephen Rothwell
2010-07-05 12:15   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200309231739.2w45cleifsmwbfd6@pali \
    --to=pali@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sj1557.seo@samsung.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.