kernel-fxtec-pro1x/drivers/message/i2o/Kconfig
David Howells 9361401eb7 [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-09-30 20:52:31 +02:00

126 lines
4.1 KiB
Text

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