mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-27 14:14:24 +08:00
a24c8b5111
There are some compile errors reported by kernel test robot:
arm-linux-gnueabi-ld: fs/romfs/storage.o: in function `romfs_dev_read':
storage.c:(.text+0x64): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x9c): undefined reference to `__bread_gfp'
arm-linux-gnueabi-ld: fs/romfs/storage.o: in function `romfs_dev_strnlen':
storage.c:(.text+0x128): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x16c): undefined reference to `__bread_gfp'
arm-linux-gnueabi-ld: fs/romfs/storage.o: in function `romfs_dev_strcmp':
storage.c:(.text+0x22c): undefined reference to `__bread_gfp'
arm-linux-gnueabi-ld: storage.c:(.text+0x27c): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x2a8): undefined reference to `__bread_gfp'
arm-linux-gnueabi-ld: storage.c:(.text+0x2bc): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x2d4): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x2f4): undefined reference to `__brelse'
arm-linux-gnueabi-ld: storage.c:(.text+0x304): undefined reference to `__brelse'
The reason for the problem is that the commit
"925c86a19bac" ("fs: add CONFIG_BUFFER_HEAD") has added a new config
"CONFIG_BUFFER_HEAD" that controls building the buffer_head code, and
romfs needs to use the buffer_head API, but no corresponding config has
beed added. Select the config "CONFIG_BUFFER_HEAD" in romfs Kconfig to
resolve the problem.
Fixes: 925c86a19b ("fs: add CONFIG_BUFFER_HEAD")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308031810.pQzGmR1v-lkp@intel.com/
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Li Zetao <lizetao1@huawei.com>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
[axboe: fold in Christoph's incremental]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
65 lines
1.9 KiB
Plaintext
65 lines
1.9 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
config ROMFS_FS
|
|
tristate "ROM file system support"
|
|
depends on BLOCK || MTD
|
|
help
|
|
This is a very small read-only file system mainly intended for
|
|
initial ram disks of installation disks, but it could be used for
|
|
other read-only media as well. Read
|
|
<file:Documentation/filesystems/romfs.rst> for details.
|
|
|
|
To compile this file system support as a module, choose M here: the
|
|
module will be called romfs. Note that the file system of your
|
|
root partition (the one containing the directory /) cannot be a
|
|
module.
|
|
|
|
If you don't know whether you need it, then you don't need it:
|
|
answer N.
|
|
|
|
#
|
|
# Select the backing stores to be supported
|
|
#
|
|
choice
|
|
prompt "RomFS backing stores"
|
|
depends on ROMFS_FS
|
|
default ROMFS_BACKED_BY_BLOCK
|
|
help
|
|
Select the backing stores to be supported.
|
|
|
|
config ROMFS_BACKED_BY_BLOCK
|
|
bool "Block device-backed ROM file system support"
|
|
depends on BLOCK
|
|
help
|
|
This permits ROMFS to use block devices buffered through the page
|
|
cache as the medium from which to retrieve data. It does not allow
|
|
direct mapping of the medium.
|
|
|
|
If unsure, answer Y.
|
|
|
|
config ROMFS_BACKED_BY_MTD
|
|
bool "MTD-backed ROM file system support"
|
|
depends on MTD=y || (ROMFS_FS=m && MTD)
|
|
help
|
|
This permits ROMFS to use MTD based devices directly, without the
|
|
intercession of the block layer (which may have been disabled). It
|
|
also allows direct mapping of MTD devices through romfs files under
|
|
NOMMU conditions if the underlying device is directly addressable by
|
|
the CPU.
|
|
|
|
If unsure, answer Y.
|
|
|
|
config ROMFS_BACKED_BY_BOTH
|
|
bool "Both the above"
|
|
depends on BLOCK && (MTD=y || (ROMFS_FS=m && MTD))
|
|
endchoice
|
|
|
|
|
|
config ROMFS_ON_BLOCK
|
|
bool
|
|
default y if ROMFS_BACKED_BY_BLOCK || ROMFS_BACKED_BY_BOTH
|
|
select BUFFER_HEAD
|
|
|
|
config ROMFS_ON_MTD
|
|
bool
|
|
default y if ROMFS_BACKED_BY_MTD || ROMFS_BACKED_BY_BOTH
|