[RFC 31/32] mars: add new module Kconfig

[Thomas Schoebel-Theuer]

Signed-off-by: Thomas Schoebel-Theuer <tst@xxxxxxxxxxxxxxxxxx>
---
 drivers/staging/mars/Kconfig | 266 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 266 insertions(+)
 create mode 100644 drivers/staging/mars/Kconfig

diff --git a/drivers/staging/mars/Kconfig b/drivers/staging/mars/Kconfig
new file mode 100644
index 000000000000..836185e9509c
--- /dev/null
+++ b/drivers/staging/mars/Kconfig
@@ -0,0 +1,266 @@
+#
+# MARS configuration
+#
+
+config MARS
+	tristate "storage system MARS (EXPERIMENTAL)"
+	depends on BLOCK && PROC_SYSCTL && HIGH_RES_TIMERS && !DEBUG_SLAB && !DEBUG_SG
+	default n
+	---help---
+	  MARS is a long-distance replication of generic block devices.
+	  It works asynchronously and tolerates network bottlenecks.
+	  Please read the full documentation at
+	    https://github.com/schoebel/mars/blob/master/docu/mars-manual.pdf?raw=true
+	  Always compile MARS as a module!
+
+config MARS_CHECKS
+	bool "enable simple runtime checks in MARS"
+	depends on MARS
+	default y
+	---help---
+	  These checks should be rather lightweight. Use them
+	  for beta testing and for production systems where
+	  safety is more important than performance.
+	  In case of bugs in the reference counting, an automatic	repair
+	  is attempted, which lowers the risk of memory corruptions.
+	  Disable only if you need the absolutely last grain of
+	  performance.
+	  If unsure, say Y here.
+
+config MARS_DEBUG
+	bool "enable full runtime checks and some tracing in MARS"
+	depends on MARS
+	default n
+	---help---
+	  Some of these checks and some additional error tracing may
+	  consume noticeable amounts of memory. However, this is extremely
+	  valuable for finding bugs, even in production systems.
+
+	  OFF for production systems. ON for testing!
+
+	  If you encounter bugs in production systems, you
+	  may / should use this also in production if you carefully
+	  monitor your systems.
+
+config MARS_DEBUG_MEM
+	bool "debug memory operations"
+	depends on MARS_DEBUG
+	default n
+	---help---
+	  This adds considerable space and time overhead, but catches
+	  many errors (including some that are not caught by kmemleak).
+
+	  OFF for production systems. ON for testing!
+	  Use only for development and thorough testing!
+
+config MARS_DEBUG_MEM_STRONG
+	bool "intensified debugging of memory operations"
+	depends on MARS_DEBUG_MEM
+	default y
+	---help---
+	  Trace all block allocations, find more errors.
+	  Adds some overhead.
+
+	  Use for debugging of new bricks or for intensified
+	  regression testing.
+
+config MARS_DEBUG_ORDER0
+	bool "also debug order0 operations"
+	depends on MARS_DEBUG_MEM
+	default n
+	---help---
+	  Turn even order 0 allocations into order 1 ones and provoke
+	  heavy memory fragmentation problems from the buddy allocator,
+	  but catch some additional memory problems.
+	  Use only if you know what you are doing!
+	  Normally OFF.
+
+config MARS_DEFAULT_PORT
+	int "port number where MARS is listening"
+	depends on MARS
+	default 7777
+	---help---
+	  Best practice is to uniformly use the same port number
+	  in a cluster. Therefore, this is a compiletime constant.
+	  You may override this at insmod time via the mars_port= parameter.
+
+config MARS_NET_COMPAT
+	bool "compatibility to 0.1 series network protocol"
+	depends on MARS
+	default y
+	---help---
+	TRANSITIONAL: this is only needed for _mixed_ operations of the
+	MARS Light 0.1 kernel modules and 0.2 module.
+	Typically, you will need this only during upgrade for minimizig
+	downtime (e.g.	first upgrade secondary side, then handover,
+	and finally upgrade the former primary side).
+	This option will be removed for 0.3 and later stable
+	series, since you will no longer need it.
+
+config MARS_LOGDIR
+	string "absolute path to the logging directory"
+	depends on MARS
+	default "/mars"
+	---help---
+	  Path to the directory where all MARS messages will reside.
+	  Usually this is equal to the global /mars directory.
+
+	  Logfiles and status files obey the following naming conventions:
+		0.debug.log
+		1.info.log
+		2.warn.log
+		3.error.log
+		4.fatal.log
+		5.total.log
+	  Logfiles must already exist in order to be appended.
+	  Logiles can be rotated by renaming them and creating
+	  a new empty file in place of the old one.
+
+	  Status files follow the same rules, but .log is replaced
+	  by .status, and they are created automatically. Their content
+	  is however limited to a few seconds or minutes.
+
+	  Leave this at the default unless you know what you are doing.
+
+config MARS_MIN_SPACE_4
+	int "absolutely necessary free space in /mars/ (hard limit in GB)"
+	depends on MARS
+	default 2
+	---help---
+	  HARDEST EMERGENCY LIMIT
+
+	  When free space in /mars/ drops under this limit,
+	  transaction logging to /mars/ will stop at all,
+	  even at all primary resources. All IO will directly go to the
+	  underlying raw devices. The transaction logfile sequence numbers
+	  will be disrupted, deliberately leaving holes in the sequence.
+
+	  This is a last-resort desperate action of the kernel.
+
+	  As a consequence, all secodaries will have no chance to
+	  replay at that gap, even if they got the logfiles.
+	  The secondaries will stop at the gap, left in an outdated,
+	  but logically consistent state.
+
+	  After the problem has been fixed, the secondaries must
+	  start a full-sync in order to continue replication at the
+	  recent state.
+
+	  This is the hardest measure the kernel can take in order
+	  to TRY to continue undisrupted operation at the primary side.
+
+	  In general, you should avoid such situations at the admin level.
+
+	  Please implement your own monitoring at the admin level,
+	  which warns you and/or takes appropriate countermeasures
+	  much earlier.
+
+	  Never rely on this emergency feature!
+
+config MARS_MIN_SPACE_3
+	int "free space in /mars/ for primary logfiles (additional limit in GB)"
+	depends on MARS
+	default 2
+	---help---
+	  MEDIUM EMERGENCY LIMIT
+
+	  When free space in /mars/ drops under
+	  MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3,
+	  elder transaction logfiles will be deleted at primary resources.
+
+	  As a consequence, the secondaries may no longer be able to
+	  get a consecute series of copies of logfiles.
+	  As a result, they may get stuck somewhere inbetween at an
+	  outdated, but logically consistent state.
+
+	  This is a desperate action of the kernel.
+
+	  After the problem has been fixed, some secondaries may need to
+	  start a full-sync in order to continue replication at the
+	  recent state.
+
+	  In general, you should avoid such situations at the admin level.
+
+	  Please implement your own monitoring at the admin level,
+	  which warns you and/or takes appropriate countermeasures
+	  much earlier.
+
+	  Never rely on this emergency feature!
+
+config MARS_MIN_SPACE_2
+	int "free space in /mars/ for secondary logfiles (additional limit in GB)"
+	depends on MARS
+	default 2
+	---help---
+	  MEDIUM EMERGENCY LIMIT
+
+	  When free space in /mars/ drops under
+	  MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2,
+	  elder transaction logfiles will be deleted at secondary resources.
+
+	  As a consequence, some local secondary resources
+	  may get stuck somewhere inbetween at an
+	  outdated, but logically consistent state.
+
+	  This is a desperate action of the kernel.
+
+	  After the problem has been fixed and the free space becomes
+	  larger than MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2
+	  + MARS_MIN_SPACE_2, the secondary tries to fetch the missing
+	  logfiles from the primary again.
+
+	  However, if the necessary logfiles have been deleted at the
+	  primary side in the meantime, this may fail.
+
+	  In general, you should avoid such situations at the admin level.
+
+	  Please implement your own monitoring at the admin level,
+	  which warns you and/or takes appropriate countermeasures
+	  much earlier.
+
+	  Never rely on this emergency feature!
+
+config MARS_MIN_SPACE_1
+	int "free space in /mars/ for replication (additional limit in GB)"
+	depends on MARS
+	default 2
+	---help---
+	  LOWEST EMERGENCY LIMIT
+
+	  When free space in /mars/ drops under MARS_MIN_SPACE_4
+	  + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2 + MARS_MIN_SPACE_1,
+	  fetching of transaction logfiles will stop at local secondary
+	  resources.
+
+	  As a consequence, some local secondary resources
+	  may get stuck somewhere inbetween at an
+	  outdated, but logically consistent state.
+
+	  This is a desperate action of the kernel.
+
+	  After the problem has been fixed and the free space becomes
+	  larger than MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2
+	  + MARS_MIN_SPACE_2, the secondary will continue fetching its
+	  copy of logfiles from the primary side.
+
+	  In general, you should avoid such situations at the admin level.
+
+	  Please implement your own monitoring at the admin level,
+	  which warns you and/or takes appropriate countermeasures
+	  much earlier.
+
+	  Never rely on this emergency feature!
+
+config MARS_MIN_SPACE_0
+	int "total space needed in /mars/ for (additional limit in GB)"
+	depends on MARS
+	default 12
+	---help---
+	  Operational pre-requirement.
+
+	  In order to use MARS, the total space available in /mars/ must
+	  be  at least MARS_MIN_SPACE_4 + MARS_MIN_SPACE_3 + MARS_MIN_SPACE_2
+	  + MARS_MIN_SPACE_1 + MARS_MIN_SPACE_0.
+
+	  If you cannot afford that amount of storage space, please use
+	  DRBD in place of MARS.
-- 
2.11.0