[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <003501d5f66b$7fe3b260$7fab1720$@samsung.com>
Date: Tue, 10 Mar 2020 08:36:04 +0900
From: "Namjae Jeon" <namjae.jeon@...sung.com>
To: 'Pali Rohár' <pali@...nel.org>,
"'Stephen Rothwell'" <sfr@...b.auug.org.au>,
"'Greg Kroah-Hartman'" <gregkh@...uxfoundation.org>
Cc: "'Al Viro'" <viro@...IV.linux.org.uk>,
"'Linux Next Mailing List'" <linux-next@...r.kernel.org>,
"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
"'Sungjong Seo'" <sj1557.seo@...sung.com>,
"'Christoph Hellwig'" <hch@....de>
Subject: RE: linux-next: build warning after merge of the vfs tree
> 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.
Agree.
Greg, You told me to let me know when fs/exfat gets accepted. Now it's time
to drop staging/exfat.
Thanks!
>
> Any objections? Or other ideas?
Powered by blists - more mailing lists