| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 15 Mar 2009 20:15:04 -0700 From: don fisher <hdf3@...cast.net> To: Nick Andrew <nick@...k-andrew.net> CC: linux-kernel@...r.kernel.org Subject: Re: [PATCH try #1] Kconfig: cleanup block/Kconfig help descriptions Nick, I am trying to configure a linux-2.6.28.7 kernel. Please explain why the switch for large block devices should be !64BIT. I have a 64BIT system and currently cannot generate files greater than 2TB. Is this the problem? Should this be true for 64BIT systems? Thanks, don Nick Andrew wrote: > 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@...k-andrew.net> > --- > I'm not sure why LSF has "If unsure, say Y." I would have thought it > pretty uncommon to have such large files. Also if you need LSF, you > probably need LBD (can NFS handle 2TB+ files?). Is this a safety > feature? How often is Grandma going to mount a filesystem containing > 2TB+ sized files? > > Also the description for BLK_DEV_BSG is pretty obscure. Can anybody > suggest why you'd want to do this or what tools you can use or even > some documentation? > > > block/Kconfig | 65 +++++++++++++++++++++++++++++++++++++-------------------- > 1 files changed, 42 insertions(+), 23 deletions(-) > > > diff --git a/block/Kconfig b/block/Kconfig > index 9bda7bc..a3d8509 100644 > --- a/block/Kconfig > +++ b/block/Kconfig > @@ -5,14 +5,18 @@ menuconfig BLOCK > bool "Enable the block layer" if EMBEDDED > default y > help > - This permits the block layer to be removed from the kernel if it's not > - needed (on some embedded devices for example). If this option is > - disabled, then blockdev files will become unusable and some > - filesystems (such as ext3) will become unavailable. > + Provide block layer support for the kernel. > > - This option will also disable SCSI character devices and USB storage > - since they make use of various block layer definitions and > - facilities. > + 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. > > Say Y here unless you know you really don't want to mount disks and > suchlike. > @@ -23,9 +27,20 @@ config LBD > bool "Support for Large Block Devices" > depends on !64BIT > help > - Say Y here if you want to attach large (bigger than 2TB) discs to > - your machine, or if you want to have a raid or loopback device > - bigger than 2TB. Otherwise say N. > + Enable block devices of size 2TB and larger. > + > + 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. > + > + For example, RAID devices are frequently bigger than the capacity > + of the largest individual hard drive. > + > + This option is not required if you have individual disk drives > + which total 2TB+ and you are not aggregating the capacity into > + a large block device (e.g. using RAID or LVM). > + > + If unsure, say N. > > config BLK_DEV_IO_TRACE > bool "Support for tracing block io actions" > @@ -33,19 +48,21 @@ config BLK_DEV_IO_TRACE > select RELAY > select DEBUG_FS > help > - Say Y here, if you want to be able to trace the block layer actions > + Say Y here if you want to be able to trace the block layer actions > on a given queue. Tracing allows you to see any traffic happening > - on a block device queue. For more information (and the user space > - support tools needed), fetch the blktrace app from: > + on a block device queue. For more information (and the userspace > + support tools needed), fetch the blktrace tools from: > > git://brick.kernel.dk/data/git/blktrace.git > > + If unsure, say N. > + > config LSF > bool "Support for Large Single Files" > depends on !64BIT > help > - Say Y here if you want to be able to handle very large files (bigger > - than 2TB), otherwise say N. > + Say Y here if you want to be able to handle very large files (2TB > + and larger), otherwise say N. > > If unsure, say Y. > > @@ -53,14 +70,16 @@ config BLK_DEV_BSG > bool "Block layer SG support v4 (EXPERIMENTAL)" > depends on EXPERIMENTAL > ---help--- > - 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). > + 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. > > endif # BLOCK > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- ----------------------------------------------------------------- | Don Fisher hdf3@...cast.net | | 865 W. Cresta Loma Dr. VOICE: (520)888-7613 | | Tucson, AZ. 85704-3705 | ----------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists