mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-14 07:36:43 +07: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>
127 lines
4.1 KiB
Plaintext
127 lines
4.1 KiB
Plaintext
|
|
menu "I2O device support"
|
|
|
|
config I2O
|
|
tristate "I2O support"
|
|
depends on PCI
|
|
---help---
|
|
The Intelligent Input/Output (I2O) architecture allows hardware
|
|
drivers to be split into two parts: an operating system specific
|
|
module called the OSM and an hardware specific module called the
|
|
HDM. The OSM can talk to a whole range of HDM's, and ideally the
|
|
HDM's are not OS dependent. This allows for the same HDM driver to
|
|
be used under different operating systems if the relevant OSM is in
|
|
place. In order for this to work, you need to have an I2O interface
|
|
adapter card in your computer. This card contains a special I/O
|
|
processor (IOP), thus allowing high speeds since the CPU does not
|
|
have to deal with I/O.
|
|
|
|
If you say Y here, you will get a choice of interface adapter
|
|
drivers and OSM's with the following questions.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
modules will be called i2o_core.
|
|
|
|
If unsure, say N.
|
|
|
|
config I2O_LCT_NOTIFY_ON_CHANGES
|
|
bool "Enable LCT notification"
|
|
depends on I2O
|
|
default y
|
|
---help---
|
|
Only say N here if you have a I2O controller from SUN. The SUN
|
|
firmware doesn't support LCT notification on changes. If this option
|
|
is enabled on such a controller the driver will hang up in a endless
|
|
loop. On all other controllers say Y.
|
|
|
|
If unsure, say Y.
|
|
|
|
config I2O_EXT_ADAPTEC
|
|
bool "Enable Adaptec extensions"
|
|
depends on I2O
|
|
default y
|
|
---help---
|
|
Say Y for support of raidutils for Adaptec I2O controllers. You also
|
|
have to say Y to "I2O Configuration support", "I2O SCSI OSM" below
|
|
and to "SCSI generic support" under "SCSI device configuration".
|
|
|
|
config I2O_EXT_ADAPTEC_DMA64
|
|
bool "Enable 64-bit DMA"
|
|
depends on I2O_EXT_ADAPTEC && ( 64BIT || HIGHMEM64G )
|
|
default y
|
|
---help---
|
|
Say Y for support of 64-bit DMA transfer mode on Adaptec I2O
|
|
controllers.
|
|
Note: You need at least firmware version 3709.
|
|
|
|
config I2O_CONFIG
|
|
tristate "I2O Configuration support"
|
|
depends on I2O
|
|
---help---
|
|
Say Y for support of the configuration interface for the I2O adapters.
|
|
If you have a RAID controller from Adaptec and you want to use the
|
|
raidutils to manage your RAID array, you have to say Y here.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
module will be called i2o_config.
|
|
|
|
Note: If you want to use the new API you have to download the
|
|
i2o_config patch from http://i2o.shadowconnect.com/
|
|
|
|
config I2O_CONFIG_OLD_IOCTL
|
|
bool "Enable ioctls (OBSOLETE)"
|
|
depends on I2O_CONFIG
|
|
default y
|
|
---help---
|
|
Enables old ioctls.
|
|
|
|
config I2O_BUS
|
|
tristate "I2O Bus Adapter OSM"
|
|
depends on I2O
|
|
---help---
|
|
Include support for the I2O Bus Adapter OSM. The Bus Adapter OSM
|
|
provides access to the busses on the I2O controller. The main purpose
|
|
is to rescan the bus to find new devices.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
module will be called i2o_bus.
|
|
|
|
config I2O_BLOCK
|
|
tristate "I2O Block OSM"
|
|
depends on I2O && BLOCK
|
|
---help---
|
|
Include support for the I2O Block OSM. The Block OSM presents disk
|
|
and other structured block devices to the operating system. If you
|
|
are using an RAID controller, you could access the array only by
|
|
the Block OSM driver. But it is possible to access the single disks
|
|
by the SCSI OSM driver, for example to monitor the disks.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
module will be called i2o_block.
|
|
|
|
config I2O_SCSI
|
|
tristate "I2O SCSI OSM"
|
|
depends on I2O && SCSI
|
|
---help---
|
|
Allows direct SCSI access to SCSI devices on a SCSI or FibreChannel
|
|
I2O controller. You can use both the SCSI and Block OSM together if
|
|
you wish. To access a RAID array, you must use the Block OSM driver.
|
|
But you could use the SCSI OSM driver to monitor the single disks.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
module will be called i2o_scsi.
|
|
|
|
config I2O_PROC
|
|
tristate "I2O /proc support"
|
|
depends on I2O
|
|
---help---
|
|
If you say Y here and to "/proc file system support", you will be
|
|
able to read I2O related information from the virtual directory
|
|
/proc/i2o.
|
|
|
|
To compile this support as a module, choose M here: the
|
|
module will be called i2o_proc.
|
|
|
|
endmenu
|
|
|