UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/block/Kconfig

85 lines
2.5 KiB
Plaintext
Raw Normal View History

[BLOCK] Move all core block layer code to new block/ directory drivers/block/ is right now a mix of core and driver parts. Lets move the core parts to a new top level directory. Al will move the fs/ related block parts to block/ next. Signed-off-by: Jens Axboe <axboe@suse.de>
2005-11-04 15:43:35 +08:00
#
# Block layer core configuration
#
Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-07-10 18:24:11 +08:00
menuconfig BLOCK
[PATCH] Only enable CONFIG_BLOCK option for embedded It's too easy for people to shoot themselves in the foot, and it only makes sense for embedded folks anyway. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2006-10-01 03:14:05 +08:00
bool "Enable the block layer" if EMBEDDED
[PATCH] BLOCK: Make it possible to disable the block layer [try #6] 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>
2006-10-01 02:45:40 +08:00
default y
help
Kconfig: clean up block/Kconfig help descriptions Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-04-21 15:51:04 +08:00
Provide block layer support for the kernel.
[PATCH] BLOCK: Make it possible to disable the block layer [try #6] 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>
2006-10-01 02:45:40 +08:00
Kconfig: clean up block/Kconfig help descriptions Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-04-21 15:51:04 +08:00
Disable this option to remove the block layer support from the
kernel. This may be useful for embedded devices.
If this option is disabled:
- block device files will become unusable
- some filesystems (such as ext3) will become unavailable.
Also, SCSI character devices and USB storage will be disabled since
they make use of various block layer definitions and facilities.
[PATCH] BLOCK: Make it possible to disable the block layer [try #6] 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>
2006-10-01 02:45:40 +08:00
Say Y here unless you know you really don't want to mount disks and
suchlike.
if BLOCK
[BLOCK] Move all core block layer code to new block/ directory drivers/block/ is right now a mix of core and driver parts. Lets move the core parts to a new top level directory. Al will move the fs/ related block parts to block/ next. Signed-off-by: Jens Axboe <axboe@suse.de>
2005-11-04 15:43:35 +08:00
config LBD
Get rid of CONFIG_LSF We have two seperate config entries for large devices/files. One is CONFIG_LBD that guards just the devices, the other is CONFIG_LSF that handles large files. This doesn't make a lot of sense, you typically want both or none. So get rid of CONFIG_LSF and change CONFIG_LBD wording to indicate that it covers both. Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-12-12 16:51:16 +08:00
bool "Support for large block devices and files"
[PATCH] Centralise definitions of sector_t and blkcnt_t CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly good reason. Centralising the definition in linux/types.h means that arch maintainers don't need to bother adding it, as well as fixing the problem with x86-64 users being asked to make a decision that has absolutely no effect. The H8/300 porters seem particularly confused since I'm not aware of any microcontrollers that need to support 2TB filesystems. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-04 18:38:31 +08:00
depends on !64BIT
block: enable by default support for large devices and files on 32-bit archs Enable by default support for large devices and files (CONFIG_LBD): - With 1TB disks being a commodity hardware it is quite easy to hit 2TB limitation while building RAIDs etc. and many distros have been using CONFIG_LBD=y by default already (at least Fedora 10 and openSUSE 11.1). - This should also prevent a subtle ext4 filesystem compatibility issue: mke2fs.ext4 defaults to creating filesystems with huge_files feature enabled and such filesystems cannot be later mounted read-write on machines with CONFIG_LBD=n (it should be quite easy to hit this issue when trying to use filesystem created using distro kernel on system running the self-build kernel, think about USB disk enclosures & co.). While at it: - Clarify config option help text w.r.t. mounting ext4 filesystems (they can be mounted with CONFIG_LBD=n but in the read-only mode). Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-04-21 15:27:03 +08:00
default y
[BLOCK] Move all core block layer code to new block/ directory drivers/block/ is right now a mix of core and driver parts. Lets move the core parts to a new top level directory. Al will move the fs/ related block parts to block/ next. Signed-off-by: Jens Axboe <axboe@suse.de>
2005-11-04 15:43:35 +08:00
help
Get rid of CONFIG_LSF We have two seperate config entries for large devices/files. One is CONFIG_LBD that guards just the devices, the other is CONFIG_LSF that handles large files. This doesn't make a lot of sense, you typically want both or none. So get rid of CONFIG_LSF and change CONFIG_LBD wording to indicate that it covers both. Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-12-12 16:51:16 +08:00
Enable block devices or files of size 2TB and larger.
Kconfig: clean up block/Kconfig help descriptions Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-04-21 15:51:04 +08:00
This option is required to support the full capacity of large
(2TB+) block devices, including RAID, disk, Network Block Device,
Logical Volume Manager (LVM) and loopback.
Get rid of CONFIG_LSF We have two seperate config entries for large devices/files. One is CONFIG_LBD that guards just the devices, the other is CONFIG_LSF that handles large files. This doesn't make a lot of sense, you typically want both or none. So get rid of CONFIG_LSF and change CONFIG_LBD wording to indicate that it covers both. Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-12-12 16:51:16 +08:00
This option also enables support for single files larger than
2TB.
Kconfig: clean up block/Kconfig help descriptions Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-04-21 15:51:04 +08:00
block: Add Kconfig help which notes that ext4 needs CONFIG_LBD Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: Jens Axboe <jens.axboe@oracle.com>
2009-01-07 04:16:33 +08:00
The ext4 filesystem requires that this feature be enabled in
order to support filesystems that have the huge_file feature
block: enable by default support for large devices and files on 32-bit archs Enable by default support for large devices and files (CONFIG_LBD): - With 1TB disks being a commodity hardware it is quite easy to hit 2TB limitation while building RAIDs etc. and many distros have been using CONFIG_LBD=y by default already (at least Fedora 10 and openSUSE 11.1). - This should also prevent a subtle ext4 filesystem compatibility issue: mke2fs.ext4 defaults to creating filesystems with huge_files feature enabled and such filesystems cannot be later mounted read-write on machines with CONFIG_LBD=n (it should be quite easy to hit this issue when trying to use filesystem created using distro kernel on system running the self-build kernel, think about USB disk enclosures & co.). While at it: - Clarify config option help text w.r.t. mounting ext4 filesystems (they can be mounted with CONFIG_LBD=n but in the read-only mode). Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-04-21 15:27:03 +08:00
enabled. Otherwise, it will refuse to mount in the read-write
mode any filesystems that use the huge_file feature, which is
enabled by default by mke2fs.ext4.
block: Add Kconfig help which notes that ext4 needs CONFIG_LBD Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: Jens Axboe <jens.axboe@oracle.com>
2009-01-07 04:16:33 +08:00
block: enable by default support for large devices and files on 32-bit archs Enable by default support for large devices and files (CONFIG_LBD): - With 1TB disks being a commodity hardware it is quite easy to hit 2TB limitation while building RAIDs etc. and many distros have been using CONFIG_LBD=y by default already (at least Fedora 10 and openSUSE 11.1). - This should also prevent a subtle ext4 filesystem compatibility issue: mke2fs.ext4 defaults to creating filesystems with huge_files feature enabled and such filesystems cannot be later mounted read-write on machines with CONFIG_LBD=n (it should be quite easy to hit this issue when trying to use filesystem created using distro kernel on system running the self-build kernel, think about USB disk enclosures & co.). While at it: - Clarify config option help text w.r.t. mounting ext4 filesystems (they can be mounted with CONFIG_LBD=n but in the read-only mode). Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-04-21 15:27:03 +08:00
The GFS2 filesystem also requires this feature.
If unsure, say Y.
[BLOCK] Move all core block layer code to new block/ directory drivers/block/ is right now a mix of core and driver parts. Lets move the core parts to a new top level directory. Al will move the fs/ related block parts to block/ next. Signed-off-by: Jens Axboe <axboe@suse.de>
2005-11-04 15:43:35 +08:00
bsg: support for full generic block layer SG v3 Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-07-09 18:38:05 +08:00
config BLK_DEV_BSG
bsg: Kconfig updates - add the detailed explanation. - remove 'default y'. - make 'EXPERIMENTAL' keyword visible to the user in menu. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-07-17 18:22:09 +08:00
bool "Block layer SG support v4 (EXPERIMENTAL)"
[SCSI] bsg: separate bsg and SCSI (so SCSI can be modular) This patch moves the bsg registration into SCSI so that bsg no longer has a dependency on the scsi_interface_register API. This can be viewed as a temporary expedient until we can get universal bsg binding sorted out properly. Also use the sdev bus_id as the generic bsg name (to avoid clashes with the queue name). Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2007-07-19 23:15:10 +08:00
depends on EXPERIMENTAL
bsg: support for full generic block layer SG v3 Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-07-09 18:38:05 +08:00
---help---
Kconfig: clean up block/Kconfig help descriptions Modify the help descriptions of block/Kconfig for clarity, accuracy and consistency. Refactor the BLOCK description a bit. The wording "This permits ... to be removed" isn't quite right; the block layer is removed when the option is disabled, whereas most descriptions talk about what happens when the option is enabled. Reformat the list of what is affected by disabling the block layer. Add more examples of large block devices to LBD and strive for technical accuracy; block devices of size _exactly_ 2TB require CONFIG_LBD, not only "bigger than 2TB". Also try to say (perhaps not very clearly) that the config option is only needed when you want to have individual block devices of size >= 2TB, for example if you had 3 x 1TB disks in your computer you'd have a total storage size of 3TB but you wouldn't need the option unless you want to aggregate those disks into a RAID or LVM. Improve terminology and grammar on BLK_DEV_IO_TRACE. I also added the boilerplate "If unsure, say N" to most options. Precisely say "2TB and larger" for LSF. Indent the help text for BLK_DEV_BSG by 2 spaces in accordance with the standard. Signed-off-by: Nick Andrew <nick@nick-andrew.net> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-04-21 15:51:04 +08:00
Saying Y here will enable generic SG (SCSI generic) v4 support
for any block device.
Unlike SG v3 (aka block/scsi_ioctl.c drivers/scsi/sg.c), SG v4
can handle complicated SCSI commands: tagged variable length cdbs
with bidirectional data transfers and generic request/response
protocols (e.g. Task Management Functions and SMP in Serial
Attached SCSI).
If unsure, say N.
bsg: support for full generic block layer SG v3 Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-07-09 18:38:05 +08:00
block: Block layer data integrity support Some block devices support verifying the integrity of requests by way of checksums or other protection information that is submitted along with the I/O. This patch implements support for generating and verifying integrity metadata, as well as correctly merging, splitting and cloning bios and requests that have this extra information attached. See Documentation/block/data-integrity.txt for more information. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-07-01 02:04:41 +08:00
config BLK_DEV_INTEGRITY
bool "Block layer data integrity support"
---help---
Some storage devices allow extra information to be
stored/retrieved to help protect the data. The block layer
data integrity option provides hooks which can be used by
filesystems to ensure better data integrity.
Say yes here if you have a storage device that provides the
T10/SCSI Data Integrity Field or the T13/ATA External Path
Protection. If in doubt, say N.
Only enable BLOCK_COMPAT if COMPAT is needed IOW, it needs to depend on both CONFIG_BLOCK and CONFIG_COMPAT. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-13 08:58:36 +08:00
endif # BLOCK
[BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-12 18:50:41 +08:00
config BLOCK_COMPAT
bool
Only enable BLOCK_COMPAT if COMPAT is needed IOW, it needs to depend on both CONFIG_BLOCK and CONFIG_COMPAT. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-13 08:58:36 +08:00
depends on BLOCK && COMPAT
[BLOCK] Only include the compat ioctl code if CONFIG_BLOCK is set Add an extra CONFIG_BLOCK_COMPAT that we can use in the Makefile Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-12 18:50:41 +08:00
default y
[BLOCK] Move all core block layer code to new block/ directory drivers/block/ is right now a mix of core and driver parts. Lets move the core parts to a new top level directory. Al will move the fs/ related block parts to block/ next. Signed-off-by: Jens Axboe <axboe@suse.de>
2005-11-04 15:43:35 +08:00
source block/Kconfig.iosched