renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-22 12:14:01 +08:00
Code
24562486be
linux-next/fs/romfs/Kconfig

63 lines
1.8 KiB
Plaintext
Raw Normal View History

fs/Kconfig: move romfs out Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
2009-01-22 16:03:34 +08:00
config ROMFS_FS
tristate "ROM file system support"
NOMMU: Fix the RomFS Kconfig to ensure at least one backing store is selected Fix the configuration of the RomFS to make sure that at least one backing store method is always selected. This is done by rendering it down to a choice item that selects between Block, MTD and both. This also works correctly in the case that CONFIG_MTD=m: MTD cannot be selected as a backing store unless CONFIG_ROMFS_FS is also 'm'. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-20 20:31:54 +08:00
depends on BLOCK || MTD
fs/Kconfig: move romfs out Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
2009-01-22 16:03:34 +08:00
---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.txt> 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.
NOMMU: Make it possible for RomFS to use MTD devices directly Change RomFS so that it can use MTD devices directly - without the intercession of the block layer - as well as using block devices. This permits RomFS: (1) to use the MTD direct mapping facility available under NOMMU conditions if the underlying device is directly accessible by the CPU (including XIP); (2) and thus to be used when the block layer is disabled. RomFS can be configured with support just for MTD devices, just for Block devices or for both. If RomFS is configured for both, then it will treat mtdblock device files as MTD backing stores, not block layer backing stores. I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV board with a RomFS image installed on the mtdram test device. I see my test program being run XIP: # cat /proc/maps ... c0c000b0-c0c01f8c r-xs 00000000 1f:00 144 /mnt/doshm ... GDB on the kernel can be used to show that these addresses are within the set-aside RAM space. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Bernd Schmidt <bernd.schmidt@analog.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-12 18:40:10 +08:00
NOMMU: Fix the RomFS Kconfig to ensure at least one backing store is selected Fix the configuration of the RomFS to make sure that at least one backing store method is always selected. This is done by rendering it down to a choice item that selects between Block, MTD and both. This also works correctly in the case that CONFIG_MTD=m: MTD cannot be selected as a backing store unless CONFIG_ROMFS_FS is also 'm'. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-20 20:31:54 +08:00
#
# 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
NOMMU: Make it possible for RomFS to use MTD devices directly Change RomFS so that it can use MTD devices directly - without the intercession of the block layer - as well as using block devices. This permits RomFS: (1) to use the MTD direct mapping facility available under NOMMU conditions if the underlying device is directly accessible by the CPU (including XIP); (2) and thus to be used when the block layer is disabled. RomFS can be configured with support just for MTD devices, just for Block devices or for both. If RomFS is configured for both, then it will treat mtdblock device files as MTD backing stores, not block layer backing stores. I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV board with a RomFS image installed on the mtdram test device. I see my test program being run XIP: # cat /proc/maps ... c0c000b0-c0c01f8c r-xs 00000000 1f:00 144 /mnt/doshm ... GDB on the kernel can be used to show that these addresses are within the set-aside RAM space. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Bernd Schmidt <bernd.schmidt@analog.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-12 18:40:10 +08:00
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.
NOMMU: Fix the RomFS Kconfig to ensure at least one backing store is selected Fix the configuration of the RomFS to make sure that at least one backing store method is always selected. This is done by rendering it down to a choice item that selects between Block, MTD and both. This also works correctly in the case that CONFIG_MTD=m: MTD cannot be selected as a backing store unless CONFIG_ROMFS_FS is also 'm'. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-20 20:31:54 +08:00
config ROMFS_BACKED_BY_MTD
NOMMU: Make it possible for RomFS to use MTD devices directly Change RomFS so that it can use MTD devices directly - without the intercession of the block layer - as well as using block devices. This permits RomFS: (1) to use the MTD direct mapping facility available under NOMMU conditions if the underlying device is directly accessible by the CPU (including XIP); (2) and thus to be used when the block layer is disabled. RomFS can be configured with support just for MTD devices, just for Block devices or for both. If RomFS is configured for both, then it will treat mtdblock device files as MTD backing stores, not block layer backing stores. I tested this using a CONFIG_MMU=n CONFIG_BLOCK=n kernel running on my FRV board with a RomFS image installed on the mtdram test device. I see my test program being run XIP: # cat /proc/maps ... c0c000b0-c0c01f8c r-xs 00000000 1f:00 144 /mnt/doshm ... GDB on the kernel can be used to show that these addresses are within the set-aside RAM space. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Bernd Schmidt <bernd.schmidt@analog.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-12 18:40:10 +08:00
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.
NOMMU: Fix the RomFS Kconfig to ensure at least one backing store is selected Fix the configuration of the RomFS to make sure that at least one backing store method is always selected. This is done by rendering it down to a choice item that selects between Block, MTD and both. This also works correctly in the case that CONFIG_MTD=m: MTD cannot be selected as a backing store unless CONFIG_ROMFS_FS is also 'm'. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-02-20 20:31:54 +08:00
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
config ROMFS_ON_MTD
bool
default y if ROMFS_BACKED_BY_MTD || ROMFS_BACKED_BY_BOTH
Copy Permalink