drm/etnaviv: Implement mmap as GEM object function
[linux-2.6-microblaze.git] / drivers / md / Kconfig
1 # SPDX-License-Identifier: GPL-2.0-only
2 #
3 # Block device driver configuration
4 #
5
6 menuconfig MD
7         bool "Multiple devices driver support (RAID and LVM)"
8         depends on BLOCK
9         select SRCU
10         help
11           Support multiple physical spindles through a single logical device.
12           Required for RAID and logical volume management.
13
14 if MD
15
16 config BLK_DEV_MD
17         tristate "RAID support"
18         help
19           This driver lets you combine several hard disk partitions into one
20           logical block device. This can be used to simply append one
21           partition to another one or to combine several redundant hard disks
22           into a RAID1/4/5 device so as to provide protection against hard
23           disk failures. This is called "Software RAID" since the combining of
24           the partitions is done by the kernel. "Hardware RAID" means that the
25           combining is done by a dedicated controller; if you have such a
26           controller, you do not need to say Y here.
27
28           More information about Software RAID on Linux is contained in the
29           Software RAID mini-HOWTO, available from
30           <https://www.tldp.org/docs.html#howto>. There you will also learn
31           where to get the supporting user space utilities raidtools.
32
33           If unsure, say N.
34
35 config MD_AUTODETECT
36         bool "Autodetect RAID arrays during kernel boot"
37         depends on BLK_DEV_MD=y
38         default y
39         help
40           If you say Y here, then the kernel will try to autodetect raid
41           arrays as part of its boot process.
42
43           If you don't use raid and say Y, this autodetection can cause
44           a several-second delay in the boot time due to various
45           synchronisation steps that are part of this step.
46
47           If unsure, say Y.
48
49 config MD_LINEAR
50         tristate "Linear (append) mode"
51         depends on BLK_DEV_MD
52         help
53           If you say Y here, then your multiple devices driver will be able to
54           use the so-called linear mode, i.e. it will combine the hard disk
55           partitions by simply appending one to the other.
56
57           To compile this as a module, choose M here: the module
58           will be called linear.
59
60           If unsure, say Y.
61
62 config MD_RAID0
63         tristate "RAID-0 (striping) mode"
64         depends on BLK_DEV_MD
65         help
66           If you say Y here, then your multiple devices driver will be able to
67           use the so-called raid0 mode, i.e. it will combine the hard disk
68           partitions into one logical device in such a fashion as to fill them
69           up evenly, one chunk here and one chunk there. This will increase
70           the throughput rate if the partitions reside on distinct disks.
71
72           Information about Software RAID on Linux is contained in the
73           Software-RAID mini-HOWTO, available from
74           <https://www.tldp.org/docs.html#howto>. There you will also
75           learn where to get the supporting user space utilities raidtools.
76
77           To compile this as a module, choose M here: the module
78           will be called raid0.
79
80           If unsure, say Y.
81
82 config MD_RAID1
83         tristate "RAID-1 (mirroring) mode"
84         depends on BLK_DEV_MD
85         help
86           A RAID-1 set consists of several disk drives which are exact copies
87           of each other.  In the event of a mirror failure, the RAID driver
88           will continue to use the operational mirrors in the set, providing
89           an error free MD (multiple device) to the higher levels of the
90           kernel.  In a set with N drives, the available space is the capacity
91           of a single drive, and the set protects against a failure of (N - 1)
92           drives.
93
94           Information about Software RAID on Linux is contained in the
95           Software-RAID mini-HOWTO, available from
96           <https://www.tldp.org/docs.html#howto>.  There you will also
97           learn where to get the supporting user space utilities raidtools.
98
99           If you want to use such a RAID-1 set, say Y.  To compile this code
100           as a module, choose M here: the module will be called raid1.
101
102           If unsure, say Y.
103
104 config MD_RAID10
105         tristate "RAID-10 (mirrored striping) mode"
106         depends on BLK_DEV_MD
107         help
108           RAID-10 provides a combination of striping (RAID-0) and
109           mirroring (RAID-1) with easier configuration and more flexible
110           layout.
111           Unlike RAID-0, but like RAID-1, RAID-10 requires all devices to
112           be the same size (or at least, only as much as the smallest device
113           will be used).
114           RAID-10 provides a variety of layouts that provide different levels
115           of redundancy and performance.
116
117           RAID-10 requires mdadm-1.7.0 or later, available at:
118
119           https://www.kernel.org/pub/linux/utils/raid/mdadm/
120
121           If unsure, say Y.
122
123 config MD_RAID456
124         tristate "RAID-4/RAID-5/RAID-6 mode"
125         depends on BLK_DEV_MD
126         select RAID6_PQ
127         select LIBCRC32C
128         select ASYNC_MEMCPY
129         select ASYNC_XOR
130         select ASYNC_PQ
131         select ASYNC_RAID6_RECOV
132         help
133           A RAID-5 set of N drives with a capacity of C MB per drive provides
134           the capacity of C * (N - 1) MB, and protects against a failure
135           of a single drive. For a given sector (row) number, (N - 1) drives
136           contain data sectors, and one drive contains the parity protection.
137           For a RAID-4 set, the parity blocks are present on a single drive,
138           while a RAID-5 set distributes the parity across the drives in one
139           of the available parity distribution methods.
140
141           A RAID-6 set of N drives with a capacity of C MB per drive
142           provides the capacity of C * (N - 2) MB, and protects
143           against a failure of any two drives. For a given sector
144           (row) number, (N - 2) drives contain data sectors, and two
145           drives contains two independent redundancy syndromes.  Like
146           RAID-5, RAID-6 distributes the syndromes across the drives
147           in one of the available parity distribution methods.
148
149           Information about Software RAID on Linux is contained in the
150           Software-RAID mini-HOWTO, available from
151           <https://www.tldp.org/docs.html#howto>. There you will also
152           learn where to get the supporting user space utilities raidtools.
153
154           If you want to use such a RAID-4/RAID-5/RAID-6 set, say Y.  To
155           compile this code as a module, choose M here: the module
156           will be called raid456.
157
158           If unsure, say Y.
159
160 config MD_MULTIPATH
161         tristate "Multipath I/O support"
162         depends on BLK_DEV_MD
163         help
164           MD_MULTIPATH provides a simple multi-path personality for use
165           the MD framework.  It is not under active development.  New
166           projects should consider using DM_MULTIPATH which has more
167           features and more testing.
168
169           If unsure, say N.
170
171 config MD_FAULTY
172         tristate "Faulty test module for MD"
173         depends on BLK_DEV_MD
174         help
175           The "faulty" module allows for a block device that occasionally returns
176           read or write errors.  It is useful for testing.
177
178           In unsure, say N.
179
180
181 config MD_CLUSTER
182         tristate "Cluster Support for MD"
183         depends on BLK_DEV_MD
184         depends on DLM
185         default n
186         help
187         Clustering support for MD devices. This enables locking and
188         synchronization across multiple systems on the cluster, so all
189         nodes in the cluster can access the MD devices simultaneously.
190
191         This brings the redundancy (and uptime) of RAID levels across the
192         nodes of the cluster. Currently, it can work with raid1 and raid10
193         (limited support).
194
195         If unsure, say N.
196
197 source "drivers/md/bcache/Kconfig"
198
199 config BLK_DEV_DM_BUILTIN
200         bool
201
202 config BLK_DEV_DM
203         tristate "Device mapper support"
204         select BLK_DEV_DM_BUILTIN
205         depends on DAX || DAX=n
206         help
207           Device-mapper is a low level volume manager.  It works by allowing
208           people to specify mappings for ranges of logical sectors.  Various
209           mapping types are available, in addition people may write their own
210           modules containing custom mappings if they wish.
211
212           Higher level volume managers such as LVM2 use this driver.
213
214           To compile this as a module, choose M here: the module will be
215           called dm-mod.
216
217           If unsure, say N.
218
219 config DM_DEBUG
220         bool "Device mapper debugging support"
221         depends on BLK_DEV_DM
222         help
223           Enable this for messages that may help debug device-mapper problems.
224
225           If unsure, say N.
226
227 config DM_BUFIO
228        tristate
229        depends on BLK_DEV_DM
230         help
231          This interface allows you to do buffered I/O on a device and acts
232          as a cache, holding recently-read blocks in memory and performing
233          delayed writes.
234
235 config DM_DEBUG_BLOCK_MANAGER_LOCKING
236        bool "Block manager locking"
237        depends on DM_BUFIO
238         help
239          Block manager locking can catch various metadata corruption issues.
240
241          If unsure, say N.
242
243 config DM_DEBUG_BLOCK_STACK_TRACING
244        bool "Keep stack trace of persistent data block lock holders"
245        depends on STACKTRACE_SUPPORT && DM_DEBUG_BLOCK_MANAGER_LOCKING
246        select STACKTRACE
247         help
248          Enable this for messages that may help debug problems with the
249          block manager locking used by thin provisioning and caching.
250
251          If unsure, say N.
252
253 config DM_BIO_PRISON
254        tristate
255        depends on BLK_DEV_DM
256         help
257          Some bio locking schemes used by other device-mapper targets
258          including thin provisioning.
259
260 source "drivers/md/persistent-data/Kconfig"
261
262 config DM_UNSTRIPED
263        tristate "Unstriped target"
264        depends on BLK_DEV_DM
265         help
266           Unstripes I/O so it is issued solely on a single drive in a HW
267           RAID0 or dm-striped target.
268
269 config DM_CRYPT
270         tristate "Crypt target support"
271         depends on BLK_DEV_DM
272         depends on (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n)
273         depends on (TRUSTED_KEYS || TRUSTED_KEYS=n)
274         select CRYPTO
275         select CRYPTO_CBC
276         select CRYPTO_ESSIV
277         help
278           This device-mapper target allows you to create a device that
279           transparently encrypts the data on it. You'll need to activate
280           the ciphers you're going to use in the cryptoapi configuration.
281
282           For further information on dm-crypt and userspace tools see:
283           <https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt>
284
285           To compile this code as a module, choose M here: the module will
286           be called dm-crypt.
287
288           If unsure, say N.
289
290 config DM_SNAPSHOT
291        tristate "Snapshot target"
292        depends on BLK_DEV_DM
293        select DM_BUFIO
294         help
295          Allow volume managers to take writable snapshots of a device.
296
297 config DM_THIN_PROVISIONING
298        tristate "Thin provisioning target"
299        depends on BLK_DEV_DM
300        select DM_PERSISTENT_DATA
301        select DM_BIO_PRISON
302         help
303          Provides thin provisioning and snapshots that share a data store.
304
305 config DM_CACHE
306        tristate "Cache target (EXPERIMENTAL)"
307        depends on BLK_DEV_DM
308        default n
309        select DM_PERSISTENT_DATA
310        select DM_BIO_PRISON
311         help
312          dm-cache attempts to improve performance of a block device by
313          moving frequently used data to a smaller, higher performance
314          device.  Different 'policy' plugins can be used to change the
315          algorithms used to select which blocks are promoted, demoted,
316          cleaned etc.  It supports writeback and writethrough modes.
317
318 config DM_CACHE_SMQ
319        tristate "Stochastic MQ Cache Policy (EXPERIMENTAL)"
320        depends on DM_CACHE
321        default y
322         help
323          A cache policy that uses a multiqueue ordered by recent hits
324          to select which blocks should be promoted and demoted.
325          This is meant to be a general purpose policy.  It prioritises
326          reads over writes.  This SMQ policy (vs MQ) offers the promise
327          of less memory utilization, improved performance and increased
328          adaptability in the face of changing workloads.
329
330 config DM_WRITECACHE
331         tristate "Writecache target"
332         depends on BLK_DEV_DM
333         help
334            The writecache target caches writes on persistent memory or SSD.
335            It is intended for databases or other programs that need extremely
336            low commit latency.
337
338            The writecache target doesn't cache reads because reads are supposed
339            to be cached in standard RAM.
340
341 config DM_EBS
342         tristate "Emulated block size target (EXPERIMENTAL)"
343         depends on BLK_DEV_DM
344         select DM_BUFIO
345         help
346           dm-ebs emulates smaller logical block size on backing devices
347           with larger ones (e.g. 512 byte sectors on 4K native disks).
348
349 config DM_ERA
350        tristate "Era target (EXPERIMENTAL)"
351        depends on BLK_DEV_DM
352        default n
353        select DM_PERSISTENT_DATA
354        select DM_BIO_PRISON
355         help
356          dm-era tracks which parts of a block device are written to
357          over time.  Useful for maintaining cache coherency when using
358          vendor snapshots.
359
360 config DM_CLONE
361        tristate "Clone target (EXPERIMENTAL)"
362        depends on BLK_DEV_DM
363        default n
364        select DM_PERSISTENT_DATA
365         help
366          dm-clone produces a one-to-one copy of an existing, read-only source
367          device into a writable destination device. The cloned device is
368          visible/mountable immediately and the copy of the source device to the
369          destination device happens in the background, in parallel with user
370          I/O.
371
372          If unsure, say N.
373
374 config DM_MIRROR
375        tristate "Mirror target"
376        depends on BLK_DEV_DM
377         help
378          Allow volume managers to mirror logical volumes, also
379          needed for live data migration tools such as 'pvmove'.
380
381 config DM_LOG_USERSPACE
382         tristate "Mirror userspace logging"
383         depends on DM_MIRROR && NET
384         select CONNECTOR
385         help
386           The userspace logging module provides a mechanism for
387           relaying the dm-dirty-log API to userspace.  Log designs
388           which are more suited to userspace implementation (e.g.
389           shared storage logs) or experimental logs can be implemented
390           by leveraging this framework.
391
392 config DM_RAID
393        tristate "RAID 1/4/5/6/10 target"
394        depends on BLK_DEV_DM
395        select MD_RAID0
396        select MD_RAID1
397        select MD_RAID10
398        select MD_RAID456
399        select BLK_DEV_MD
400         help
401          A dm target that supports RAID1, RAID10, RAID4, RAID5 and RAID6 mappings
402
403          A RAID-5 set of N drives with a capacity of C MB per drive provides
404          the capacity of C * (N - 1) MB, and protects against a failure
405          of a single drive. For a given sector (row) number, (N - 1) drives
406          contain data sectors, and one drive contains the parity protection.
407          For a RAID-4 set, the parity blocks are present on a single drive,
408          while a RAID-5 set distributes the parity across the drives in one
409          of the available parity distribution methods.
410
411          A RAID-6 set of N drives with a capacity of C MB per drive
412          provides the capacity of C * (N - 2) MB, and protects
413          against a failure of any two drives. For a given sector
414          (row) number, (N - 2) drives contain data sectors, and two
415          drives contains two independent redundancy syndromes.  Like
416          RAID-5, RAID-6 distributes the syndromes across the drives
417          in one of the available parity distribution methods.
418
419 config DM_ZERO
420         tristate "Zero target"
421         depends on BLK_DEV_DM
422         help
423           A target that discards writes, and returns all zeroes for
424           reads.  Useful in some recovery situations.
425
426 config DM_MULTIPATH
427         tristate "Multipath target"
428         depends on BLK_DEV_DM
429         # nasty syntax but means make DM_MULTIPATH independent
430         # of SCSI_DH if the latter isn't defined but if
431         # it is, DM_MULTIPATH must depend on it.  We get a build
432         # error if SCSI_DH=m and DM_MULTIPATH=y
433         depends on !SCSI_DH || SCSI
434         help
435           Allow volume managers to support multipath hardware.
436
437 config DM_MULTIPATH_QL
438         tristate "I/O Path Selector based on the number of in-flight I/Os"
439         depends on DM_MULTIPATH
440         help
441           This path selector is a dynamic load balancer which selects
442           the path with the least number of in-flight I/Os.
443
444           If unsure, say N.
445
446 config DM_MULTIPATH_ST
447         tristate "I/O Path Selector based on the service time"
448         depends on DM_MULTIPATH
449         help
450           This path selector is a dynamic load balancer which selects
451           the path expected to complete the incoming I/O in the shortest
452           time.
453
454           If unsure, say N.
455
456 config DM_MULTIPATH_HST
457         tristate "I/O Path Selector based on historical service time"
458         depends on DM_MULTIPATH
459         help
460           This path selector is a dynamic load balancer which selects
461           the path expected to complete the incoming I/O in the shortest
462           time by comparing estimated service time (based on historical
463           service time).
464
465           If unsure, say N.
466
467 config DM_MULTIPATH_IOA
468         tristate "I/O Path Selector based on CPU submission"
469         depends on DM_MULTIPATH
470         help
471           This path selector selects the path based on the CPU the IO is
472           executed on and the CPU to path mapping setup at path addition time.
473
474           If unsure, say N.
475
476 config DM_DELAY
477         tristate "I/O delaying target"
478         depends on BLK_DEV_DM
479         help
480         A target that delays reads and/or writes and can send
481         them to different devices.  Useful for testing.
482
483         If unsure, say N.
484
485 config DM_DUST
486         tristate "Bad sector simulation target"
487         depends on BLK_DEV_DM
488         help
489         A target that simulates bad sector behavior.
490         Useful for testing.
491
492         If unsure, say N.
493
494 config DM_INIT
495         bool "DM \"dm-mod.create=\" parameter support"
496         depends on BLK_DEV_DM=y
497         help
498         Enable "dm-mod.create=" parameter to create mapped devices at init time.
499         This option is useful to allow mounting rootfs without requiring an
500         initramfs.
501         See Documentation/admin-guide/device-mapper/dm-init.rst for dm-mod.create="..."
502         format.
503
504         If unsure, say N.
505
506 config DM_UEVENT
507         bool "DM uevents"
508         depends on BLK_DEV_DM
509         help
510         Generate udev events for DM events.
511
512 config DM_FLAKEY
513        tristate "Flakey target"
514        depends on BLK_DEV_DM
515         help
516          A target that intermittently fails I/O for debugging purposes.
517
518 config DM_VERITY
519         tristate "Verity target support"
520         depends on BLK_DEV_DM
521         select CRYPTO
522         select CRYPTO_HASH
523         select DM_BUFIO
524         help
525           This device-mapper target creates a read-only device that
526           transparently validates the data on one underlying device against
527           a pre-generated tree of cryptographic checksums stored on a second
528           device.
529
530           You'll need to activate the digests you're going to use in the
531           cryptoapi configuration.
532
533           To compile this code as a module, choose M here: the module will
534           be called dm-verity.
535
536           If unsure, say N.
537
538 config DM_VERITY_VERIFY_ROOTHASH_SIG
539         def_bool n
540         bool "Verity data device root hash signature verification support"
541         depends on DM_VERITY
542         select SYSTEM_DATA_VERIFICATION
543         help
544           Add ability for dm-verity device to be validated if the
545           pre-generated tree of cryptographic checksums passed has a pkcs#7
546           signature file that can validate the roothash of the tree.
547
548           By default, rely on the builtin trusted keyring.
549
550           If unsure, say N.
551
552 config DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING
553         bool "Verity data device root hash signature verification with secondary keyring"
554         depends on DM_VERITY_VERIFY_ROOTHASH_SIG
555         depends on SECONDARY_TRUSTED_KEYRING
556         help
557           Rely on the secondary trusted keyring to verify dm-verity signatures.
558
559           If unsure, say N.
560
561 config DM_VERITY_FEC
562         bool "Verity forward error correction support"
563         depends on DM_VERITY
564         select REED_SOLOMON
565         select REED_SOLOMON_DEC8
566         help
567           Add forward error correction support to dm-verity. This option
568           makes it possible to use pre-generated error correction data to
569           recover from corrupted blocks.
570
571           If unsure, say N.
572
573 config DM_SWITCH
574         tristate "Switch target support (EXPERIMENTAL)"
575         depends on BLK_DEV_DM
576         help
577           This device-mapper target creates a device that supports an arbitrary
578           mapping of fixed-size regions of I/O across a fixed set of paths.
579           The path used for any specific region can be switched dynamically
580           by sending the target a message.
581
582           To compile this code as a module, choose M here: the module will
583           be called dm-switch.
584
585           If unsure, say N.
586
587 config DM_LOG_WRITES
588         tristate "Log writes target support"
589         depends on BLK_DEV_DM
590         help
591           This device-mapper target takes two devices, one device to use
592           normally, one to log all write operations done to the first device.
593           This is for use by file system developers wishing to verify that
594           their fs is writing a consistent file system at all times by allowing
595           them to replay the log in a variety of ways and to check the
596           contents.
597
598           To compile this code as a module, choose M here: the module will
599           be called dm-log-writes.
600
601           If unsure, say N.
602
603 config DM_INTEGRITY
604         tristate "Integrity target support"
605         depends on BLK_DEV_DM
606         select BLK_DEV_INTEGRITY
607         select DM_BUFIO
608         select CRYPTO
609         select CRYPTO_SKCIPHER
610         select ASYNC_XOR
611         help
612           This device-mapper target emulates a block device that has
613           additional per-sector tags that can be used for storing
614           integrity information.
615
616           This integrity target is used with the dm-crypt target to
617           provide authenticated disk encryption or it can be used
618           standalone.
619
620           To compile this code as a module, choose M here: the module will
621           be called dm-integrity.
622
623 config DM_ZONED
624         tristate "Drive-managed zoned block device target support"
625         depends on BLK_DEV_DM
626         depends on BLK_DEV_ZONED
627         select CRC32
628         help
629           This device-mapper target takes a host-managed or host-aware zoned
630           block device and exposes most of its capacity as a regular block
631           device (drive-managed zoned block device) without any write
632           constraints. This is mainly intended for use with file systems that
633           do not natively support zoned block devices but still want to
634           benefit from the increased capacity offered by SMR disks. Other uses
635           by applications using raw block devices (for example object stores)
636           are also possible.
637
638           To compile this code as a module, choose M here: the module will
639           be called dm-zoned.
640
641           If unsure, say N.
642
643 endif # MD