License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
#
# Block device driver configuration
#
2007-07-10 14:26:06 +04:00
menuconfig BLK_DEV
bool "Block devices"
depends on BLOCK
default y
2020-06-13 19:50:22 +03:00
help
2007-08-18 14:56:21 +04:00
Say Y here to get to see options for various different block device
drivers. This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled;
only do this if you know what you are doing.
[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 22:45:40 +04:00
2007-07-10 14:26:06 +04:00
if BLK_DEV
2005-04-17 02:20:36 +04:00
2020-11-20 04:55:19 +03:00
source "drivers/block/null_blk/Kconfig"
2013-10-25 14:52:25 +04:00
2005-04-17 02:20:36 +04:00
config BLK_DEV_FD
tristate "Normal floppy disk support"
2005-09-06 04:48:42 +04:00
depends on ARCH_MAY_HAVE_PC_FDC
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
If you want to use the floppy disk drive(s) of your PC under Linux,
say Y. Information about this driver, especially important for IBM
2008-11-14 00:33:24 +03:00
Thinkpad users, is contained in
2019-06-18 17:47:10 +03:00
<file:Documentation/admin-guide/blockdev/floppy.rst>.
2005-04-17 02:20:36 +04:00
That file also contains the location of the Floppy driver FAQ as
well as location of the fdutils package used to configure additional
parameters of the driver at run time.
To compile this driver as a module, choose M here: the
module will be called floppy.
2022-04-26 23:41:05 +03:00
config BLK_DEV_FD_RAWCMD
bool "Support for raw floppy disk commands (DEPRECATED)"
depends on BLK_DEV_FD
help
If you want to use actual physical floppies and expect to do
special low-level hardware accesses to them (access and use
non-standard formats, for example), then enable this.
Note that the code enabled by this option is rarely used and
might be unstable or insecure, and distros should not enable it.
Note: FDRAWCMD is deprecated and will be removed from the kernel
in the near future.
If unsure, say N.
2005-04-17 02:20:36 +04:00
config AMIGA_FLOPPY
tristate "Amiga floppy support"
depends on AMIGA
config ATARI_FLOPPY
tristate "Atari floppy support"
depends on ATARI
config MAC_FLOPPY
tristate "Support for PowerMac floppy"
depends on PPC_PMAC && !PPC_PMAC64
help
If you have a SWIM-3 (Super Woz Integrated Machine 3; from Apple)
floppy controller, say Y here. Most commonly found in PowerMacs.
2008-11-15 18:10:10 +03:00
config BLK_DEV_SWIM
tristate "Support for SWIM Macintosh floppy"
2021-04-06 09:17:25 +03:00
depends on M68K && MAC && !HIGHMEM
2008-11-15 18:10:10 +03:00
help
You should select this option if you want floppy support
and you don't have a II, IIfx, Q900, Q950 or AV series.
2005-04-17 02:20:36 +04:00
config AMIGA_Z2RAM
tristate "Amiga Zorro II ramdisk support"
depends on ZORRO
help
This enables support for using Chip RAM and Zorro II RAM as a
ramdisk or as a swap partition. Say Y if you want to include this
driver in the kernel.
To compile this driver as a module, choose M here: the
module will be called z2ram.
2021-01-23 10:53:27 +03:00
config N64CART
bool "N64 cart support"
depends on MACH_NINTENDO64
help
Support for the N64 cart.
2017-10-30 19:02:19 +03:00
config CDROM
2017-11-03 20:00:03 +03:00
tristate
2017-10-30 19:02:19 +03:00
2010-05-11 11:02:55 +04:00
config GDROM
tristate "SEGA Dreamcast GD-ROM drive"
depends on SH_DREAMCAST
2017-10-30 19:02:19 +03:00
select CDROM
2010-05-11 11:02:55 +04:00
help
A standard SEGA Dreamcast comes with a modified CD ROM drive called a
"GD-ROM" by SEGA to signify it is capable of reading special disks
with up to 1 GB of data. This drive will also read standard CD ROM
disks. Select this option to access any disks in your GD ROM drive.
Most users will want to say "Y" here.
You can also build this as a module which will be called gdrom.
2011-08-30 18:34:26 +04:00
source "drivers/block/mtip32xx/Kconfig"
zram: promote zram from staging
Zram has lived in staging for a LONG LONG time and have been
fixed/improved by many contributors so code is clean and stable now. Of
course, there are lots of product using zram in real practice.
The major TV companys have used zram as swap since two years ago and
recently our production team released android smart phone with zram
which is used as swap, too and recently Android Kitkat start to use zram
for small memory smart phone. And there was a report Google released
their ChromeOS with zram, too and cyanogenmod have been used zram long
time ago. And I heard some disto have used zram block device for tmpfs.
In addition, I saw many report from many other peoples. For example,
Lubuntu start to use it.
The benefit of zram is very clear. With my experience, one of the
benefit was to remove jitter of video application with backgroud memory
pressure. It would be effect of efficient memory usage by compression
but more issue is whether swap is there or not in the system. Recent
mobile platforms have used JAVA so there are many anonymous pages. But
embedded system normally are reluctant to use eMMC or SDCard as swap
because there is wear-leveling and latency issues so if we do not use
swap, it means we can't reclaim anoymous pages and at last, we could
encounter OOM kill. :(
Although we have real storage as swap, it was a problem, too. Because
it sometime ends up making system very unresponsible caused by slow swap
storage performance.
Quote from Luigi on Google
"Since Chrome OS was mentioned: the main reason why we don't use swap
to a disk (rotating or SSD) is because it doesn't degrade gracefully
and leads to a bad interactive experience. Generally we prefer to
manage RAM at a higher level, by transparently killing and restarting
processes. But we noticed that zram is fast enough to be competitive
with the latter, and it lets us make more efficient use of the
available RAM. " and he announced.
http://www.spinics.net/lists/linux-mm/msg57717.html
Other uses case is to use zram for block device. Zram is block device
so anyone can format the block device and mount on it so some guys on
the internet start zram as /var/tmp.
http://forums.gentoo.org/viewtopic-t-838198-start-0.html
Let's promote zram and enhance/maintain it instead of removing.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Pekka Enberg <penberg@kernel.org>
Cc: Bob Liu <bob.liu@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-01-31 03:45:52 +04:00
source "drivers/block/zram/Kconfig"
2005-04-17 02:20:36 +04:00
config BLK_DEV_UBD
bool "Virtual block device"
depends on UML
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
The User-Mode Linux port includes a driver called UBD which will let
you access arbitrary files on the host computer as block devices.
Unless you know that you do not need such virtual block devices say
Y here.
config BLK_DEV_UBD_SYNC
bool "Always do synchronous disk IO for UBD"
depends on BLK_DEV_UBD
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
Writes to the virtual block device are not immediately written to the
host's disk; this may cause problems if, for example, the User-Mode
Linux 'Virtual Machine' uses a journalling filesystem and the host
computer crashes.
Synchronous operation (i.e. always writing data to the host's disk
immediately) is configurable on a per-UBD basis by using a special
kernel command line option. Alternatively, you can say Y here to
turn on synchronous operation by default for all block devices.
If you're running a journalling file system (like reiserfs, for
example) in your virtual machine, you will want to say Y here. If
you care for the safety of the data in your virtual machine, Y is a
wise choice too. In all other cases (for example, if you're just
playing around with User-Mode Linux) you can choose N.
config BLK_DEV_COW_COMMON
bool
default BLK_DEV_UBD
config BLK_DEV_LOOP
tristate "Loopback device support"
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
Saying Y here will allow you to use a regular file as a block
device; you can then create a file system on that block device and
mount it just as you would mount other block devices such as hard
drive partitions, CD-ROM drives or floppy drives. The loop devices
are block special device files with major number 7 and typically
called /dev/loop0, /dev/loop1 etc.
This is useful if you want to check an ISO 9660 file system before
burning the CD, or if you want to use floppy images without first
writing them to floppy. Furthermore, some Linux distributions avoid
the need for a dedicated Linux partition by keeping their complete
root file system inside a DOS FAT file using this loop device
driver.
To use the loop device, you need the losetup utility, found in the
util-linux package, see
2017-03-27 15:44:06 +03:00
<https://www.kernel.org/pub/linux/utils/util-linux/>.
2005-04-17 02:20:36 +04:00
The loop device driver can also be used to "hide" a file system in
a disk partition, floppy, or regular file, either using encryption
(scrambling the data) or steganography (hiding the data in the low
bits of, say, a sound file). This is also safe if the file resides
on a remote file server.
Note that this loop device has nothing to do with the loopback
device used for network connections from the machine to itself.
To compile this driver as a module, choose M here: the
module will be called loop.
Most users will answer N here.
2011-08-01 00:08:04 +04:00
config BLK_DEV_LOOP_MIN_COUNT
int "Number of loop devices to pre-create at init time"
depends on BLK_DEV_LOOP
default 8
help
Static number of loop devices to be unconditionally pre-created
at init time.
This default value can be overwritten on the kernel command
line or with module-parameter loop.max_loop.
The historic default is 8. If a late 2011 version of losetup(8)
is used, it can be set to 0, since needed loop devices can be
dynamically allocated with the /dev/loop-control interface.
2009-09-26 03:07:19 +04:00
source "drivers/block/drbd/Kconfig"
2005-04-17 02:20:36 +04:00
config BLK_DEV_NBD
tristate "Network block device support"
depends on NET
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
Saying Y here will allow your computer to be a client for network
block devices, i.e. it will be able to use block devices exported by
servers (mount file systems on them etc.). Communication between
client and server works over TCP/IP networking, but to the client
program this is hidden: it looks like a regular local file access to
a block device special file such as /dev/nd0.
Network block devices also allows you to run a block-device in
userland (making server and client physically the same computer,
communicating using the loopback network device).
2019-06-18 17:47:10 +03:00
Read <file:Documentation/admin-guide/blockdev/nbd.rst> for more information,
2008-11-14 00:33:24 +03:00
especially about where to find the server code, which runs in user
space and does not need special kernel support.
2005-04-17 02:20:36 +04:00
Note that this has nothing to do with the network file systems NFS
or Coda; you can say N here even if you intend to use NFS or Coda.
To compile this driver as a module, choose M here: the
module will be called nbd.
If unsure, say N.
config BLK_DEV_RAM
rewrite rd
This is a rewrite of the ramdisk block device driver.
The old one is really difficult because it effectively implements a block
device which serves data out of its own buffer cache. It relies on the dirty
bit being set, to pin its backing store in cache, however there are non
trivial paths which can clear the dirty bit (eg. try_to_free_buffers()),
which had recently lead to data corruption. And in general it is completely
wrong for a block device driver to do this.
The new one is more like a regular block device driver. It has no idea about
vm/vfs stuff. It's backing store is similar to the buffer cache (a simple
radix-tree of pages), but it doesn't know anything about page cache (the pages
in the radix tree are not pagecache pages).
There is one slight downside -- direct block device access and filesystem
metadata access goes through an extra copy and gets stored in RAM twice.
However, this downside is only slight, because the real buffercache of the
device is now reclaimable (because we're not playing crazy games with it), so
under memory intensive situations, footprint should effectively be the same --
maybe even a slight advantage to the new driver because it can also reclaim
buffer heads.
The fact that it now goes through all the regular vm/fs paths makes it
much more useful for testing, too.
text data bss dec hex filename
2837 849 384 4070 fe6 drivers/block/rd.o
3528 371 12 3911 f47 drivers/block/brd.o
Text is larger, but data and bss are smaller, making total size smaller.
A few other nice things about it:
- Similar structure and layout to the new loop device handlinag.
- Dynamic ramdisk creation.
- Runtime flexible buffer head size (because it is no longer part of the
ramdisk code).
- Boot / load time flexible ramdisk size, which could easily be extended
to a per-ramdisk runtime changeable size (eg. with an ioctl).
- Can use highmem for the backing store.
[akpm@linux-foundation.org: fix build]
[byron.bbradley@gmail.com: make rd_size non-static]
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Byron Bradley <byron.bbradley@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 15:19:49 +03:00
tristate "RAM block device support"
2020-06-13 19:50:22 +03:00
help
2005-04-17 02:20:36 +04:00
Saying Y here will allow you to use a portion of your RAM memory as
a block device, so that you can make file systems on it, read and
write to it and do all the other things that you can do with normal
block devices (such as hard drives). It is usually used to load and
store a copy of a minimal root file system off of a floppy into RAM
during the initial install of Linux.
2008-11-14 00:33:24 +03:00
Note that the kernel command line option "ramdisk=XX" is now obsolete.
2019-06-18 17:47:10 +03:00
For details, read <file:Documentation/admin-guide/blockdev/ramdisk.rst>.
2005-04-17 02:20:36 +04:00
To compile this driver as a module, choose M here: the
2014-01-24 03:53:46 +04:00
module will be called brd. An alias "rd" has been defined
for historical reasons.
2005-04-17 02:20:36 +04:00
Most normal users won't need the RAM disk functionality, and can
thus say N here.
config BLK_DEV_RAM_COUNT
2006-03-28 13:56:17 +04:00
int "Default number of RAM disks"
2005-04-17 02:20:36 +04:00
default "16"
2006-03-28 13:56:17 +04:00
depends on BLK_DEV_RAM
2005-04-17 02:20:36 +04:00
help
2007-10-20 01:05:02 +04:00
The default value is 16 RAM disks. Change this if you know what you
2005-04-17 02:20:36 +04:00
are doing. If you boot from a filesystem that needs to be extracted
in memory, you will need at least one RAM disk (e.g. root on cramfs).
config BLK_DEV_RAM_SIZE
int "Default RAM disk size (kbytes)"
depends on BLK_DEV_RAM
default "4096"
help
The default value is 4096 kilobytes. Only change this if you know
2007-10-20 01:05:02 +04:00
what you are doing.
2005-04-17 02:20:36 +04:00
2023-01-05 00:44:13 +03:00
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media (DEPRECATED)"
depends on !UML
depends on SCSI
select CDROM
help
Note: This driver is deprecated and will be removed from the
kernel in the near future!
If you have a CDROM/DVD drive that supports packet writing, say
Y to include support. It should work with any MMC/Mt Fuji
compliant ATAPI or SCSI drive, which is just about any newer
DVD/CD writer.
Currently only writing to CD-RW, DVD-RW, DVD+RW and DVDRAM discs
is possible.
DVD-RW disks must be in restricted overwrite mode.
See the file <file:Documentation/cdrom/packet-writing.rst>
for further information on the use of this driver.
To compile this driver as a module, choose M here: the
module will be called pktcdvd.
config CDROM_PKTCDVD_BUFFERS
int "Free buffers for data gathering"
depends on CDROM_PKTCDVD
default "8"
help
This controls the maximum number of active concurrent packets. More
concurrent packets can increase write performance, but also require
more memory. Each concurrent packet will require approximately 64Kb
of non-swappable kernel memory, memory which will be allocated when
a disc is opened for writing.
config CDROM_PKTCDVD_WCACHE
bool "Enable write caching"
depends on CDROM_PKTCDVD
help
If enabled, write caching will be set for the CD-R/W device. For now
this option is dangerous unless the CD-RW media is known good, as we
don't do deferred write error handling yet.
2005-04-17 02:20:36 +04:00
config ATA_OVER_ETH
tristate "ATA over Ethernet support"
depends on NET
help
This driver provides Support for ATA over Ethernet block
devices like the Coraid EtherDrive (R) Storage Blade.
2007-07-16 15:03:56 +04:00
config SUNVDC
tristate "Sun Virtual Disk Client support"
depends on SUN_LDOMS
help
Support for virtual disk devices as a client under Sun
Logical Domains.
2007-05-10 17:46:00 +04:00
source "drivers/s390/block/Kconfig"
2007-07-17 15:03:39 +04:00
2007-07-18 05:37:06 +04:00
config XEN_BLKDEV_FRONTEND
tristate "Xen virtual block device support"
depends on XEN
default y
2009-02-09 23:05:51 +03:00
select XEN_XENBUS_FRONTEND
2007-07-18 05:37:06 +04:00
help
This driver implements the front-end of the Xen virtual
block device driver. It communicates with a back-end driver
in another domain which drives the actual block device.
2011-04-18 22:24:23 +04:00
config XEN_BLKDEV_BACKEND
2011-08-03 19:12:17 +04:00
tristate "Xen block-device backend driver"
2011-04-18 22:24:23 +04:00
depends on XEN_BACKEND
help
The block-device backend driver allows the kernel to export its
block devices to other guests via a high-performance shared-memory
interface.
2011-05-13 00:10:55 +04:00
The corresponding Linux frontend driver is enabled by the
CONFIG_XEN_BLKDEV_FRONTEND configuration option.
The backend driver attaches itself to a any block device specified
in the XenBus configuration. There are no limits to what the block
device as long as it has a major and minor.
If you are compiling a kernel to run in a Xen block backend driver
domain (often this is domain 0) you should say Y here. To
compile this driver as a module, chose M here: the module
will be called xen-blkback.
2007-10-22 05:03:38 +04:00
config VIRTIO_BLK
2012-10-24 00:01:51 +04:00
tristate "Virtio block driver"
depends on VIRTIO
2021-09-01 16:14:34 +03:00
select SG_POOL
2020-06-13 19:50:22 +03:00
help
2007-11-08 05:46:31 +03:00
This is the virtual block driver for virtio. It can be used with
2017-08-16 20:31:57 +03:00
QEMU based VMMs (like KVM or Xen). Say Y or M.
2007-10-22 05:03:38 +04:00
2010-08-13 03:11:25 +04:00
config BLK_DEV_RBD
tristate "Rados block device (RBD)"
2012-10-24 00:01:51 +04:00
depends on INET && BLOCK
2010-08-13 03:11:25 +04:00
select CEPH_LIB
select LIBCRC32C
select CRYPTO_AES
select CRYPTO
help
Say Y here if you want include the Rados block device, which stripes
a block device over objects stored in the Ceph distributed object
store.
More information at http://ceph.newdream.net/.
If unsure, say N.
ublk_drv: add io_uring based userspace block driver
This is the driver part of userspace block driver(ublk driver), the other
part is userspace daemon part(ublksrv)[1].
The two parts communicate by io_uring's IORING_OP_URING_CMD with one
shared cmd buffer for storing io command, and the buffer is read only for
ublksrv, each io command is indexed by io request tag directly, and is
written by ublk driver.
For example, when one READ io request is submitted to ublk block driver,
ublk driver stores the io command into cmd buffer first, then completes
one IORING_OP_URING_CMD for notifying ublksrv, and the URING_CMD is issued
to ublk driver beforehand by ublksrv for getting notification of any new
io request, and each URING_CMD is associated with one io request by tag.
After ublksrv gets the io command, it translates and handles the ublk io
request, such as, for the ublk-loop target, ublksrv translates the request
into same request on another file or disk, like the kernel loop block
driver. In ublksrv's implementation, the io is still handled by io_uring,
and share same ring with IORING_OP_URING_CMD command. When the target io
request is done, the same IORING_OP_URING_CMD is issued to ublk driver for
both committing io request result and getting future notification of new
io request.
Another thing done by ublk driver is to copy data between kernel io
request and ublksrv's io buffer:
1) before ubsrv handles WRITE request, copy the request's data into
ublksrv's userspace io buffer, so that ublksrv can handle the write
request
2) after ubsrv handles READ request, copy ublksrv's userspace io buffer
into this READ request, then ublk driver can complete the READ request
Zero copy may be switched if mm is ready to support it.
ublk driver doesn't handle any logic of the specific user space driver,
so it is small/simple enough.
[1] ublksrv
https://github.com/ming1/ubdsrv
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20220713140711.97356-2-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-07-13 17:07:10 +03:00
config BLK_DEV_UBLK
tristate "Userspace block driver (Experimental)"
select IO_URING
help
io_uring based userspace block driver. Together with ublk server, ublk
has been working well, but interface with userspace or command data
definition isn't finalized yet, and might change according to future
requirement, so mark is as experimental now.
2022-10-29 04:04:30 +03:00
Say Y if you want to get better performance because task_work_add()
can be used in IO path for replacing io_uring cmd, which will become
shared between IO tasks and ubq daemon, meantime task_work_add() can
can handle batch more effectively, but task_work_add() isn't exported
for module, so ublk has to be built to kernel.
2023-04-18 16:18:10 +03:00
config BLKDEV_UBLK_LEGACY_OPCODES
bool "Support legacy command opcode"
depends on BLK_DEV_UBLK
default y
help
ublk driver started to take plain command encoding, which turns out
one bad way. The traditional ioctl command opcode encodes more
info and basically defines each code uniquely, so opcode conflict
is avoided, and driver can handle wrong command easily, meantime it
may help security subsystem to audit io_uring command.
Say Y if your application still uses legacy command opcode.
Say N if you don't want to support legacy command opcode. It is
suggested to enable N if your application(ublk server) switches to
ioctl command encoding.
2020-05-11 16:51:29 +03:00
source "drivers/block/rnbd/Kconfig"
2007-07-10 14:26:06 +04:00
endif # BLK_DEV
