mirror of
https://github.com/torvalds/linux.git
synced 2024-11-13 23:51:39 +00:00
9361401eb7
Make it possible to disable the block layer. Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.
This patch does the following:
(*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
support.
(*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
an item that uses the block layer. This includes:
(*) Block I/O tracing.
(*) Disk partition code.
(*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
(*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
block layer to do scheduling. Some drivers that use SCSI facilities -
such as USB storage - end up disabled indirectly from this.
(*) Various block-based device drivers, such as IDE and the old CDROM
drivers.
(*) MTD blockdev handling and FTL.
(*) JFFS - which uses set_bdev_super(), something it could avoid doing by
taking a leaf out of JFFS2's book.
(*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
however, still used in places, and so is still available.
(*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
parts of linux/fs.h.
(*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
(*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
(*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
is not enabled.
(*) fs/no-block.c is created to hold out-of-line stubs and things that are
required when CONFIG_BLOCK is not set:
(*) Default blockdev file operations (to give error ENODEV on opening).
(*) Makes some /proc changes:
(*) /proc/devices does not list any blockdevs.
(*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
(*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
(*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
given command other than Q_SYNC or if a special device is specified.
(*) In init/do_mounts.c, no reference is made to the blockdev routines if
CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.
(*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
error ENOSYS by way of cond_syscall if so).
(*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
286 lines
10 KiB
Plaintext
286 lines
10 KiB
Plaintext
# $Id: Kconfig,v 1.11 2005/11/07 11:14:19 gleixner Exp $
|
|
|
|
menu "Memory Technology Devices (MTD)"
|
|
|
|
config MTD
|
|
tristate "Memory Technology Device (MTD) support"
|
|
help
|
|
Memory Technology Devices are flash, RAM and similar chips, often
|
|
used for solid state file systems on embedded devices. This option
|
|
will provide the generic support for MTD drivers to register
|
|
themselves with the kernel and for potential users of MTD devices
|
|
to enumerate the devices which are present and obtain a handle on
|
|
them. It will also allow you to select individual drivers for
|
|
particular hardware and users of MTD devices. If unsure, say N.
|
|
|
|
config MTD_DEBUG
|
|
bool "Debugging"
|
|
depends on MTD
|
|
help
|
|
This turns on low-level debugging for the entire MTD sub-system.
|
|
Normally, you should say 'N'.
|
|
|
|
config MTD_DEBUG_VERBOSE
|
|
int "Debugging verbosity (0 = quiet, 3 = noisy)"
|
|
depends on MTD_DEBUG
|
|
default "0"
|
|
help
|
|
Determines the verbosity level of the MTD debugging messages.
|
|
|
|
config MTD_CONCAT
|
|
tristate "MTD concatenating support"
|
|
depends on MTD
|
|
help
|
|
Support for concatenating several MTD devices into a single
|
|
(virtual) one. This allows you to have -for example- a JFFS(2)
|
|
file system spanning multiple physical flash chips. If unsure,
|
|
say 'Y'.
|
|
|
|
config MTD_PARTITIONS
|
|
bool "MTD partitioning support"
|
|
depends on MTD
|
|
help
|
|
If you have a device which needs to divide its flash chip(s) up
|
|
into multiple 'partitions', each of which appears to the user as
|
|
a separate MTD device, you require this option to be enabled. If
|
|
unsure, say 'Y'.
|
|
|
|
Note, however, that you don't need this option for the DiskOnChip
|
|
devices. Partitioning on NFTL 'devices' is a different - that's the
|
|
'normal' form of partitioning used on a block device.
|
|
|
|
config MTD_REDBOOT_PARTS
|
|
tristate "RedBoot partition table parsing"
|
|
depends on MTD_PARTITIONS
|
|
---help---
|
|
RedBoot is a ROM monitor and bootloader which deals with multiple
|
|
'images' in flash devices by putting a table one of the erase
|
|
blocks on the device, similar to a partition table, which gives
|
|
the offsets, lengths and names of all the images stored in the
|
|
flash.
|
|
|
|
If you need code which can detect and parse this table, and register
|
|
MTD 'partitions' corresponding to each image in the table, enable
|
|
this option.
|
|
|
|
You will still need the parsing functions to be called by the driver
|
|
for your particular device. It won't happen automatically. The
|
|
SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
|
|
example.
|
|
|
|
config MTD_REDBOOT_DIRECTORY_BLOCK
|
|
int "Location of RedBoot partition table"
|
|
depends on MTD_REDBOOT_PARTS
|
|
default "-1"
|
|
---help---
|
|
This option is the Linux counterpart to the
|
|
CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
|
|
option.
|
|
|
|
The option specifies which Flash sectors holds the RedBoot
|
|
partition table. A zero or positive value gives an absolute
|
|
erase block number. A negative value specifies a number of
|
|
sectors before the end of the device.
|
|
|
|
For example "2" means block number 2, "-1" means the last
|
|
block and "-2" means the penultimate block.
|
|
|
|
config MTD_REDBOOT_PARTS_UNALLOCATED
|
|
bool "Include unallocated flash regions"
|
|
depends on MTD_REDBOOT_PARTS
|
|
help
|
|
If you need to register each unallocated flash region as a MTD
|
|
'partition', enable this option.
|
|
|
|
config MTD_REDBOOT_PARTS_READONLY
|
|
bool "Force read-only for RedBoot system images"
|
|
depends on MTD_REDBOOT_PARTS
|
|
help
|
|
If you need to force read-only for 'RedBoot', 'RedBoot Config' and
|
|
'FIS directory' images, enable this option.
|
|
|
|
config MTD_CMDLINE_PARTS
|
|
bool "Command line partition table parsing"
|
|
depends on MTD_PARTITIONS = "y" && MTD = "y"
|
|
---help---
|
|
Allow generic configuration of the MTD partition tables via the kernel
|
|
command line. Multiple flash resources are supported for hardware where
|
|
different kinds of flash memory are available.
|
|
|
|
You will still need the parsing functions to be called by the driver
|
|
for your particular device. It won't happen automatically. The
|
|
SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
|
|
example.
|
|
|
|
The format for the command line is as follows:
|
|
|
|
mtdparts=<mtddef>[;<mtddef]
|
|
<mtddef> := <mtd-id>:<partdef>[,<partdef>]
|
|
<partdef> := <size>[@offset][<name>][ro]
|
|
<mtd-id> := unique id used in mapping driver/device
|
|
<size> := standard linux memsize OR "-" to denote all
|
|
remaining space
|
|
<name> := (NAME)
|
|
|
|
Due to the way Linux handles the command line, no spaces are
|
|
allowed in the partition definition, including mtd id's and partition
|
|
names.
|
|
|
|
Examples:
|
|
|
|
1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
|
|
mtdparts=sa1100:-
|
|
|
|
Same flash, but 2 named partitions, the first one being read-only:
|
|
mtdparts=sa1100:256k(ARMboot)ro,-(root)
|
|
|
|
If unsure, say 'N'.
|
|
|
|
config MTD_AFS_PARTS
|
|
tristate "ARM Firmware Suite partition parsing"
|
|
depends on ARM && MTD_PARTITIONS
|
|
---help---
|
|
The ARM Firmware Suite allows the user to divide flash devices into
|
|
multiple 'images'. Each such image has a header containing its name
|
|
and offset/size etc.
|
|
|
|
If you need code which can detect and parse these tables, and
|
|
register MTD 'partitions' corresponding to each image detected,
|
|
enable this option.
|
|
|
|
You will still need the parsing functions to be called by the driver
|
|
for your particular device. It won't happen automatically. The
|
|
'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
|
|
|
|
comment "User Modules And Translation Layers"
|
|
depends on MTD
|
|
|
|
config MTD_CHAR
|
|
tristate "Direct char device access to MTD devices"
|
|
depends on MTD
|
|
help
|
|
This provides a character device for each MTD device present in
|
|
the system, allowing the user to read and write directly to the
|
|
memory chips, and also use ioctl() to obtain information about
|
|
the device, or to erase parts of it.
|
|
|
|
config MTD_BLOCK
|
|
tristate "Caching block device access to MTD devices"
|
|
depends on MTD && BLOCK
|
|
---help---
|
|
Although most flash chips have an erase size too large to be useful
|
|
as block devices, it is possible to use MTD devices which are based
|
|
on RAM chips in this manner. This block device is a user of MTD
|
|
devices performing that function.
|
|
|
|
At the moment, it is also required for the Journalling Flash File
|
|
System(s) to obtain a handle on the MTD device when it's mounted
|
|
(although JFFS and JFFS2 don't actually use any of the functionality
|
|
of the mtdblock device).
|
|
|
|
Later, it may be extended to perform read/erase/modify/write cycles
|
|
on flash chips to emulate a smaller block size. Needless to say,
|
|
this is very unsafe, but could be useful for file systems which are
|
|
almost never written to.
|
|
|
|
You do not need this option for use with the DiskOnChip devices. For
|
|
those, enable NFTL support (CONFIG_NFTL) instead.
|
|
|
|
config MTD_BLOCK_RO
|
|
tristate "Readonly block device access to MTD devices"
|
|
depends on MTD_BLOCK!=y && MTD && BLOCK
|
|
help
|
|
This allows you to mount read-only file systems (such as cramfs)
|
|
from an MTD device, without the overhead (and danger) of the caching
|
|
driver.
|
|
|
|
You do not need this option for use with the DiskOnChip devices. For
|
|
those, enable NFTL support (CONFIG_NFTL) instead.
|
|
|
|
config FTL
|
|
tristate "FTL (Flash Translation Layer) support"
|
|
depends on MTD && BLOCK
|
|
---help---
|
|
This provides support for the original Flash Translation Layer which
|
|
is part of the PCMCIA specification. It uses a kind of pseudo-
|
|
file system on a flash device to emulate a block device with
|
|
512-byte sectors, on top of which you put a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on PCMCIA
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config NFTL
|
|
tristate "NFTL (NAND Flash Translation Layer) support"
|
|
depends on MTD && BLOCK
|
|
---help---
|
|
This provides support for the NAND Flash Translation Layer which is
|
|
used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
|
|
file system on a flash device to emulate a block device with
|
|
512-byte sectors, on top of which you put a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on DiskOnChip
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config NFTL_RW
|
|
bool "Write support for NFTL"
|
|
depends on NFTL
|
|
help
|
|
Support for writing to the NAND Flash Translation Layer, as used
|
|
on the DiskOnChip.
|
|
|
|
config INFTL
|
|
tristate "INFTL (Inverse NAND Flash Translation Layer) support"
|
|
depends on MTD && BLOCK
|
|
---help---
|
|
This provides support for the Inverse NAND Flash Translation
|
|
Layer which is used on M-Systems' newer DiskOnChip devices. It
|
|
uses a kind of pseudo-file system on a flash device to emulate
|
|
a block device with 512-byte sectors, on top of which you put
|
|
a 'normal' file system.
|
|
|
|
You may find that the algorithms used in this code are patented
|
|
unless you live in the Free World where software patents aren't
|
|
legal - in the USA you are only permitted to use this on DiskOnChip
|
|
hardware, although under the terms of the GPL you're obviously
|
|
permitted to copy, modify and distribute the code as you wish. Just
|
|
not use it.
|
|
|
|
config RFD_FTL
|
|
tristate "Resident Flash Disk (Flash Translation Layer) support"
|
|
depends on MTD && BLOCK
|
|
---help---
|
|
This provides support for the flash translation layer known
|
|
as the Resident Flash Disk (RFD), as used by the Embedded BIOS
|
|
of General Software. There is a blurb at:
|
|
|
|
http://www.gensw.com/pages/prod/bios/rfd.htm
|
|
|
|
config SSFDC
|
|
tristate "NAND SSFDC (SmartMedia) read only translation layer"
|
|
depends on MTD
|
|
default n
|
|
help
|
|
This enables read only access to SmartMedia formatted NAND
|
|
flash. You can mount it with FAT file system.
|
|
|
|
source "drivers/mtd/chips/Kconfig"
|
|
|
|
source "drivers/mtd/maps/Kconfig"
|
|
|
|
source "drivers/mtd/devices/Kconfig"
|
|
|
|
source "drivers/mtd/nand/Kconfig"
|
|
|
|
source "drivers/mtd/onenand/Kconfig"
|
|
|
|
endmenu
|
|
|