Staging: dst: kconfig and makefile changes.

Signed-off-by: Evgeniy Polaykov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 211af86a6c559a5ca9eff122436457ba6de43ed2..e319c67c5964a66f78173bf60f5c6d6b16ef2e20 100644 (file)
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -93,5 +93,7 @@ source "drivers/staging/epl/Kconfig"
 
 source "drivers/staging/android/Kconfig"
 
+source "drivers/staging/dst/Kconfig"
+
 endif # !STAGING_EXCLUDE_BUILD
 endif # STAGING

diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 47a56f5ffabcc5d0bedb75a4651f4a3882241a75..1971299a82fd3309b2a8eb12f13b466a24fe4775 100644 (file)
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_INPUT_MIMIO)     += mimio/
 obj-$(CONFIG_TRANZPORT)                += frontier/
 obj-$(CONFIG_EPL)              += epl/
 obj-$(CONFIG_ANDROID)          += android/
+obj-$(CONFIG_DST)              += dst/

diff --git a/drivers/staging/dst/Kconfig b/drivers/staging/dst/Kconfig
new file mode 100644 (file)
index 0000000..12ffa37
--- /dev/null
+++ b/drivers/staging/dst/Kconfig
@@ -0,0 +1,71 @@
+config DST
+       tristate "Distributed storage"
+       depends on NET && CRYPTO && SYSFS
+       select CONNECTOR
+       select LIBCRC32C
+       ---help---
+       DST is a network block device storage, which can be used to organize
+       exported storages on the remote nodes into the local block device.
+
+       DST is a network block device storage, which can be used to organize
+       exported storages on the remote nodes into the local block device.
+
+       DST works on top of any network media and protocol, it is just a matter
+       of configuration utility to understand the correct addresses. The most
+       common example is TCP over IP allows to pass through firewalls and
+       created remote backup storage in the different datacenter. DST requires
+       single port to be enabled on the exporting node and outgoing connections
+       on the local node.
+
+       DST works with in-kernel client and server, which improves the performance
+       eliminating unneded data copies and allows not to depend on the version
+       of the external IO components. It requires userspace configuration utility
+       though.
+
+       DST uses transaction model, when each store has to be explicitly acked
+       from the remote node to be considered as successfully written. There
+       may be lots of in-flight transactions. When remote host does not ack
+       the transaction it will be resent predefined number of times with specified
+       timeouts between them. All those parameters are configurable. Transactions
+       are marked as failed after all resends completed unsuccessfully, having
+       long enough resend timeout and/or large number of resends allows not to
+       return error to the higher (FS usually) layer in case of short network
+       problems or remote node outages. In case of network RAID setup this means
+       that storage will not degrade until transactions are marked as failed, and
+       thus will not force checksum recalculation and data rebuild. In case of
+       connection failure DST will try to reconnect to the remote node automatically.
+       DST sends ping commands at idle time to detect if remote node is alive.
+
+       Because of transactional model it is possible to use zero-copy sending
+       without worry of data corruption (which in turn could be detected by the
+       strong checksums though).
+
+       DST may fully encrypt the data channel in case of untrusted channel and implement
+       strong checksum of the transferred data. It is possible to configure algorithms
+       and crypto keys, they should match on both sides of the network channel.
+       Crypto processing does not introduce noticeble performance overhead, since DST
+       uses configurable pool of threads to perform crypto processing.
+
+       DST utilizes memory pool model of all its transaction allocations (it is the
+       only additional allocation on the client) and server allocations (bio pools,
+       while pages are allocated from the slab).
+
+       At startup DST performs a simple negotiation with the export node to determine
+       access permissions and size of the exported storage. It can be extended if
+       new parameters should be autonegotiated.
+
+       DST carries block IO flags in the protocol, which allows to transparently implement
+       barriers and sync/flush operations. Those flags are used in the export node where
+       IO against the local storage is performed, which means that sync write will be sync
+       on the remote node too, which in turn improves data integrity and improved resistance
+       to errors and data corruption during power outages or storage damages.
+
+       Homepage: http://www.ioremap.net/projects/dst
+       Userspace configuration utility and the latest releases: http://www.ioremap.net/archive/dst/
+
+config DST_DEBUG
+       bool "DST debug"
+       depends on DST
+       ---help---
+       This option will turn HEAVY debugging of the DST.
+       Turn it on ONLY if you have to debug some really obscure problem.

diff --git a/drivers/staging/dst/Makefile b/drivers/staging/dst/Makefile
new file mode 100644 (file)
index 0000000..3a8b0cf
--- /dev/null
+++ b/drivers/staging/dst/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DST) += nst.o
+
+nst-y := dcore.o state.o export.o thread_pool.o crypto.o trans.o