This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via 5c69d869bc287afd48d57c841e1d68728e646cbb (commit)
from 45caf39520a1f7aac3e40265bc46bc4dba695cbc (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 5c69d869bc287afd48d57c841e1d68728e646cbb
Author: Matias Elo <matias.elo(a)nokia.com>
Date: Thu Jan 17 13:06:10 2019 +0200
travis: add dpdk 18.11 test
Signed-off-by: Matias Elo <matias.elo(a)nokia.com>
Reviewed-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/.travis.yml b/.travis.yml
index c308d5ed..bbcec4fd 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -155,6 +155,18 @@ jobs:
-e ODP_CONFIG_FILE=/odp/platform/linux-generic/test/process-mode.conf
-e ODPH_PROC_MODE=1
${DOCKER_NAMESPACE}/travis-odp-lng-ubuntu_16.04 /odp/scripts/ci/check.sh
+ - stage: test
+ env: TEST=dpdk_18.11
+ install:
+ - true
+ compiler: gcc
+ script:
+ - if [ -z "${DOCKER_NAMESPACE}" ] ; then export DOCKER_NAMESPACE="opendataplane"; fi
+ - docker run --privileged -i -t
+ -v `pwd`:/odp --shm-size 8g
+ -e CC="${CC}"
+ -e CONF=""
+ ${DOCKER_NAMESPACE}/travis-odp-lng-ubuntu_16.04-dpdk_18.11 /odp/scripts/ci/check.sh
- stage: test
env: TEST=inline_timer
install:
-----------------------------------------------------------------------
Summary of changes:
.travis.yml | 12 ++++++++++++
1 file changed, 12 insertions(+)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via 45caf39520a1f7aac3e40265bc46bc4dba695cbc (commit)
from de255937275a99cebe62f159f3fc7c4b70bc04bb (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 45caf39520a1f7aac3e40265bc46bc4dba695cbc
Author: Matias Elo <matias.elo(a)nokia.com>
Date: Thu Jan 17 11:12:16 2019 +0200
linux-gen: dpdk: add a fallback value for the number of numa nodes
numa_num_configured_nodes() may return 0 on some platforms. In that case
use 1 as a replacement value.
Signed-off-by: Matias Elo <matias.elo(a)nokia.com>
Reviewed-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/platform/linux-generic/pktio/dpdk.c b/platform/linux-generic/pktio/dpdk.c
index 1edd2488..1d322057 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -1197,7 +1197,11 @@ static int dpdk_pktio_init(void)
}
mem_str_len = snprintf(NULL, 0, "%d,", DPDK_MEMORY_MB);
+
+ /* numa_num_configured_nodes() may return 0 on some platforms */
numa_nodes = numa_num_configured_nodes();
+ if (numa_nodes <= 0)
+ numa_nodes = 1;
char mem_str[mem_str_len * numa_nodes];
-----------------------------------------------------------------------
Summary of changes:
platform/linux-generic/pktio/dpdk.c | 4 ++++
1 file changed, 4 insertions(+)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via de255937275a99cebe62f159f3fc7c4b70bc04bb (commit)
from c419dc00dd13fc2760ae1dbe370a3285893c58f6 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit de255937275a99cebe62f159f3fc7c4b70bc04bb
Author: Matias Elo <matias.elo(a)nokia.com>
Date: Wed Jan 16 15:31:51 2019 +0200
test: odp_pktio_ordered: add missing schedule_config initialization
Signed-off-by: Matias Elo <matias.elo(a)nokia.com>
Reported-by: Jari Mustajärvi <jari.mustajarvi(a)nokia-bell-labs.com>
Reviewed-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/test/performance/odp_pktio_ordered.c b/test/performance/odp_pktio_ordered.c
index 15229aeb..51ec03ce 100644
--- a/test/performance/odp_pktio_ordered.c
+++ b/test/performance/odp_pktio_ordered.c
@@ -1130,7 +1130,8 @@ int main(int argc, char *argv[])
/* Parse and store the application arguments */
parse_args(argc, argv, &gbl_args->appl);
- odp_schedule_config(NULL);
+ odp_schedule_config_init(&schedule_config);
+ odp_schedule_config(&schedule_config);
if (gbl_args->appl.in_mode == SCHED_ORDERED) {
/* At least one ordered lock required */
-----------------------------------------------------------------------
Summary of changes:
test/performance/odp_pktio_ordered.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via c419dc00dd13fc2760ae1dbe370a3285893c58f6 (commit)
from eac3c037e7547b1ed1a15f0ee2e0daccacc88ec5 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit c419dc00dd13fc2760ae1dbe370a3285893c58f6
Author: Bill Fischofer <bill.fischofer(a)linaro.org>
Date: Thu Dec 27 10:04:43 2018 -0600
doc: userguide: add documentation for flow aware scheduler mode
Update the ODP User Guide to include information on scheduler
capabilities and configuration and operating in flow aware mode.
Signed-off-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Reviewed-by: Petri Savolainen <petri.savolainen(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 8ed581f5..4ec7cd72 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -965,7 +965,7 @@ same value on all ODP threads, for a given memory block, in this case)
Note that ODP implementations may have restrictions of the amount of memory
which can be allocated with this flag.
-== Queues
+== Queues and the Scheduler
Queues are the fundamental event sequencing mechanism provided by ODP and all
ODP applications make use of them either explicitly or implicitly. Queues are
created via the 'odp_queue_create()' API that returns a handle of type
@@ -1184,11 +1184,179 @@ until the locking order for this lock for all prior events has been resolved
and then enters the critical section. The *odp_schedule_order_unlock()* call
releases the critical section and allows the next order to enter it.
+=== Scheduler Capabilities and Configuration
+As with other ODP components, the ODP scheduler offers a range of capabilities
+and configuration options that are used by applications to control its
+behavior.
+
+The sequence of API calls used by applications that make use of the scheduler
+is as follows:
+
+.ODP API Scheduler Usage
+[source,c]
+-----
+odp_schedule_capability()
+odp_schedule_config_init()
+odp_schedule_config()
+odp_schedule()
+-----
+The `odp_schedule_capability()` API returns an `odp_schedule_capability_t`
+struct that defines various limits and capabilities offered by this
+implementation of the ODP scheduler:
+
+.ODP Scheduler Capabilities
+[source,c]
+-----
+/**
+ * Scheduler capabilities
+ */
+typedef struct odp_schedule_capability_t {
+ /** Maximum number of ordered locks per queue */
+ uint32_t max_ordered_locks;
+
+ /** Maximum number of scheduling groups */
+ uint32_t max_groups;
+
+ /** Number of scheduling priorities */
+ uint32_t max_prios;
+
+ /** Maximum number of scheduled (ODP_BLOCKING) queues of the default
+ * size. */
+ uint32_t max_queues;
+
+ /** Maximum number of events a scheduled (ODP_BLOCKING) queue can store
+ * simultaneously. The value of zero means that scheduled queues do not
+ * have a size limit, but a single queue can store all available
+ * events. */
+ uint32_t max_queue_size;
+
+ /** Maximum flow ID per queue
+ *
+ * Valid flow ID range in flow aware mode of scheduling is from 0 to
+ * this maximum value. So, maximum number of flows per queue is this
+ * value plus one. A value of 0 indicates that flow aware mode is not
+ * supported. */
+ uint32_t max_flow_id;
+
+ /** Lock-free (ODP_NONBLOCKING_LF) queues support.
+ * The specification is the same as for the blocking implementation. */
+ odp_support_t lockfree_queues;
+
+ /** Wait-free (ODP_NONBLOCKING_WF) queues support.
+ * The specification is the same as for the blocking implementation. */
+ odp_support_t waitfree_queues;
+
+} odp_schedule_capability_t;
+-----
+This struct indicates the various scheduling limits supported by this ODP
+implementation. Of note is the `max_flow_id` capability, which indicates
+whether this implementation is able to operate in _flow aware mode_.
+
+==== Flow Aware Scheduling
+A _flow_ is a sequence of events that share some application-specific meaning
+and context. A good example of a flow might be a TCP connection. Various
+events associated with that connection, such as packets containing
+connection data, as well as associated timeout events used for transmission
+control, are logically connected and meaningful to the application processing
+that TCP connection.
+
+Normally a single flow is associated with an ODP queue. That is, all events
+on a given queue belong to the same flow. So the queue id is synonymous with
+the flow id for those events. However, this is not without drawbacks. Queues
+are relatively heavyweight objects and provide both synchronization as well as
+user contexts. The number of queues supported by a given implementation
+(`max_queues`) may be less than the number of flows an application needs to
+be able to process.
+
+To address these needs, ODP allows schedulers to operate in flow aware mode
+in which flow id is maintained separately as part of each event. Two new
+APIs:
+
+* `odp_event_flow_id()`
+* `odp_event_flow_id_set()`
+
+are used to query and set a 32-bit flow id associated with individual events.
+The assignment and interpretation of individual flow ids is under application
+control.
+
+When operating in flow aware mode, it is the combination of flow id and
+queue id that is used by the scheduler in making scheduling decisions. So,
+for example, an Atomic queue would normally be able to dispatch events only a
+single thread at a time. When operating in flow aware mode, however, the
+scheduler will provide this exclusion only when two events on the same atomic
+queue have the same flow id. If they have different flow ids, then they can be
+scheduled concurrently to different threads.
+
+Note that when operating in this mode, any sharing of queue context must be
+done with application-provided synchronization controls (similar to how
+parallel queues behave).
+
+==== Scheduler Configuration
+After determining the scheduler's capabilities, but before starting to use
+the scheduler to process events, applications must configure the scheduler
+by calling `odp_schedule_config()`.
+
+The argument to this call is the `odp_schedule_config_t` struct:
+
+.ODP Scheduler Configuration
+[source,c]
+-----
+/**
+ * Schedule configuration
+ */
+typedef struct odp_schedule_config_t {
+ /** Maximum number of scheduled queues to be supported.
+ *
+ * @see odp_schedule_capability_t
+ */
+ uint32_t num_queues;
+
+ /** Maximum number of events required to be stored simultaneously in
+ * scheduled queue. This number must not exceed 'max_queue_size'
+ * capability. A value of 0 configures default queue size supported by
+ * the implementation.
+ */
+ uint32_t queue_size;
+
+ /** Maximum flow ID per queue
+ *
+ * This value must not exceed 'max_flow_id' capability. Flow aware
+ * mode of scheduling is enabled when the value is greater than 0.
+ * The default value is 0.
+ *
+ * Application can assign events to specific flows by calling
+ * odp_event_flow_id_set() before enqueuing events into a scheduled
+ * queue. When in flow aware mode, the event flow id value affects
+ * scheduling of the event and synchronization is maintained per flow
+ * within each queue.
+ *
+ * Depeding on implementation, there may be much more flows supported
+ * than queues, as flows are lightweight entities.
+ *
+ * @see odp_schedule_capability_t, odp_event_flow_id()
+ */
+ uint32_t max_flow_id;
+
+} odp_schedule_config_t;
+-----
+The `odp_schedule_config_init()` API should be used to initialize this
+struct to its default values. The application then sets whatever
+overrides it needs prior to calling `odp_schedule_config()` to activate
+them. Note that `NULL` may be passed as the argument to `odp_schedule_config()`
+if the application simply wants to use the implementation-defined default
+configuration. In the default configuration, the scheduler does not operate in
+flow aware mode.
+
+Once configured, `odp_schedule()` calls can be made to get events. It is
+a programming error to attempt to use the scheduler before it has been
+configured.
+
=== Queue Scheduling Summary
NOTE: Both ordered and parallel queues improve throughput over atomic queues
due to parallel event processing, but require that the application take
-steps to ensure context data synchronization if needed.
+steps to ensure context data synchronization if needed. The same is true for
+atomic queues when the scheduler is operating in flow aware mode.
include::users-guide-packet.adoc[]
-----------------------------------------------------------------------
Summary of changes:
doc/users-guide/users-guide.adoc | 172 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 170 insertions(+), 2 deletions(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, api-next has been updated
via 2c93306bd2efe1a5716067609949eccd67d493a3 (commit)
from 00385dbab270b585291cf197f62cd4d7f92c2af9 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 2c93306bd2efe1a5716067609949eccd67d493a3
Author: Bill Fischofer <bill.fischofer(a)linaro.org>
Date: Fri Dec 28 11:41:02 2018 -0600
doc: userguide: add section for compression support
Add section to User's Guide for compression and
decompression support
Signed-off-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Reviewed-by: Petri Savolainen <petri.savolainen(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/doc/users-guide/Makefile.am b/doc/users-guide/Makefile.am
index 6b2e818d..f5386dfa 100644
--- a/doc/users-guide/Makefile.am
+++ b/doc/users-guide/Makefile.am
@@ -2,6 +2,7 @@ include ../Makefile.inc
SRC = users-guide.adoc \
users-guide-cls.adoc \
+ users-guide-comp.adoc \
users-guide-crypto.adoc \
users-guide-ipsec.adoc \
users-guide-packet.adoc \
diff --git a/doc/users-guide/users-guide-comp.adoc b/doc/users-guide/users-guide-comp.adoc
new file mode 100644
index 00000000..11a39a0c
--- /dev/null
+++ b/doc/users-guide/users-guide-comp.adoc
@@ -0,0 +1,168 @@
+== Compression services
+ODP provides APIs to perform compression and decompression operations required
+by applications. ODP compression APIs are session based and provide
+compression algorithm offload services, with and without associated
+integrity hashing. This section covers the main compression APIs.
+
+ODP provides support for the following compression algorithms:
+
+`ODP_COMP_ALG_NONE`::
+The null compression algorithm. Used for testing as well as to
+specify hash-only operations.
+`ODP_COMP_ALG_DEFLATE`::
+The deflate compression algorithm specified by
+https://www.ietf.org/rfc/rfc1951.txt[RFC 1951].
+`ODP_COMP_ALG_ZLIB`::
+The ZLIB compression algorithm specified by
+https://www.ietf.org/rfc/rfc1950.txt[RFC 1950].
+`ODP_COMP_ALG_LZS`::
+The LZS compression algorithm as specified by ANSI X3.241.
+
+The following hash algorithms are also defined to be used in conjunction
+with these compression algorithms:
+
+`ODP_COMP_HASH_ALG_NONE`::
+A dummy that specifies no associated hashing is to be performed.
+`ODP_COMP_HASH_ALG_SHA1`::
+SHA-1 hashing with a 64-bit digest length.
+`ODP_COMP_HASH_ALG_SHA256`::
+SHA-2 hashing with a 256-bit digest length.
+
+=== Compression Sessions
+ODP compression services are session based and operate on input packets and
+deliver output packets. A compression session (`odp_comp_session_t`) provides
+the context for controlling the operations performed on packets. All of the
+packets processed by a session share the parameters that define the
+session.
+
+ODP supports synchronous and asynchronous compression sessions. For
+asynchronous sessions, the output of a compression operation is posted to
+a queue defined as the completion queue in its session parameters.
+
+Other session parameters include: the type of operation (compression or
+decompression), the operating mode (synchronous or asynchronous), the
+compression and hashing algorithms to be used, as well as any parameters
+needed by those algorithms to configure them. For asynchronous compression
+sessions, the application also specifies whether queue order must be
+maintained. Additional throughput may be achieved in some implementations if
+strict ordering is not required.
+
+The parameters that describe the characteristics of a compression session
+are encoded in the `odp_comp_session_param_t` struct that is passed to the
+`odp_comp_session_create()` API. A successful call returns an
+`odp_comp_session_t` handle that is then used as an input parameter to
+compression operation calls.
+
+When an application is finished with a compression session, the
+`odp_comp_session_destroy()` API is used to release the resources
+associated with an `odp_comp_session_t`.
+
+=== Compression operations
+After session creation, a compression operation can be applied to a packet
+in one of two ways: synchronous and asynchronous, depending on how the
+session was created.
+
+==== Synchronous compression operations
+Synchronous compression operations take the following form:
+
+.Invoking synchronous compression operations
+[source,c]
+-----
+int odp_comp_op(const odp_packet_t pkt_in[], odp_packet_t pkt_out[],
+ int num_pkt, const odp_comp_packet_op_param_t param[]);
+-----
+An input packet array is compressed/decompressed into a supplied output
+packet array under the control of a supplied parameter struct.
+
+The supplied `odp_comp_packet_op_param_t` struct looks as follows:
+
+.ODP compression parameter structure
+[source,c]
+-----
+/**
+ * Compression per packet operation parameters
+ */
+typedef struct odp_comp_packet_op_param_t {
+ /** Session handle */
+ odp_comp_session_t session;
+
+ /** Input data range to process. where,
+ *
+ * offset - starting offset
+ * length - length of data for compression operation
+ * */
+ odp_packet_data_range_t in_data_range;
+
+ /** Output packet data range.
+ * Indicates where processed packet will be written. where,
+ *
+ * offset - starting offset
+ * length - length of buffer available for output
+ *
+ * Output packet data is not modified outside of this provided data
+ * range. If output data length is not sufficient for compression
+ * operation ODP_COMP_STATUS_OUT_OF_SPACE_TERM error will occur
+ */
+ odp_packet_data_range_t out_data_range;
+} odp_comp_packet_op_param_t;
+-----
+Note that this struct points to the session used to control the operation and
+specifies the input and output packet data ranges to be used for the
+operation. For input, the output data range must be sufficiently sized to
+contain the result of the operation to avoid an out of space error. Upon
+output, this range is updated to reflect the actual data written. This
+information can then be used to trim off any excess padding before
+continuing processing of the output packet(s).
+
+==== Asynchronous compression operations
+Asynchronous compression operations are invoked with a slightly
+different API:
+
+.Invoking asynchronous compression operations
+[source,c]
+-----
+int odp_comp_op_enq(const odp_packet_t pkt_in[], odp_packet_t pkt_out[],
+ int num_pkt, const odp_comp_packet_op_param_t param[]);
+-----
+Here the session pointed to by the `odp_comp_packet_op_param_t` indicates
+the completion queue to be used for the operation, so a zero return from
+`odp_comp_op_enq()` means only that the operation was successfully
+initiated.
+
+The resulting completion queue can then be polled either directly
+via `odp_queue_deq()` or indirectly via the scheduler. The result is
+presented as an event of type `ODP_EVENT_PACKET` with subtype
+`ODP_EVENT_PACKET_COMP`.
+
+When receiving this event, the `odp_comp_packet_from_event()` API is used to
+convert the event into a usable `odp_packet_t`, and the `odp_comp_result()`
+API is used to retrieve the `odp_comp_packet_result_t` metadata associated
+with this packet. This struct looks as follows:
+
+.Compression output result
+[source,c]
+-----
+/**
+ * Compression packet operation result
+ */
+typedef struct odp_comp_packet_result_t {
+ /** Operation status code */
+ odp_comp_status_t status;
+
+ /** Input packet handle */
+ odp_packet_t pkt_in;
+
+ /** Output packet data range
+ * Specifies offset and length of data resulting from compression
+ * operation. When hashing is configured output_data_range.len equals
+ * length of output data + length of digest.
+ */
+ odp_packet_data_range_t output_data_range;
+} odp_comp_packet_result_t;
+-----
+Note that if the originating `odp_comp_op_enq()` call specified an array of
+input packets, each of these generates a separate result event. The order of
+these events on the completion queue associated with the compression session is
+controlled by the session's `packet_order` flag. If this flag is set then the
+results will be in the same order as the original input list. If not, then
+results are free to be reordered to make them available as soon as possible.
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 8ed581f5..dce457ff 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -1200,6 +1200,8 @@ include::users-guide-crypto.adoc[]
include::users-guide-ipsec.adoc[]
+include::users-guide-comp.adoc[]
+
include::users-guide-tm.adoc[]
include::users-guide-cls.adoc[]
-----------------------------------------------------------------------
Summary of changes:
doc/users-guide/Makefile.am | 1 +
doc/users-guide/users-guide-comp.adoc | 168 ++++++++++++++++++++++++++++++++++
doc/users-guide/users-guide.adoc | 2 +
3 files changed, 171 insertions(+)
create mode 100644 doc/users-guide/users-guide-comp.adoc
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via eac3c037e7547b1ed1a15f0ee2e0daccacc88ec5 (commit)
from 87a81d8b4feb08fdf60a960ac2b003233fc0ae3b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit eac3c037e7547b1ed1a15f0ee2e0daccacc88ec5
Author: Petri Savolainen <petri.savolainen(a)linaro.org>
Date: Fri Jan 4 16:21:02 2019 +0200
dependencies: add libconfig package name
Added apt-get and yum package names for libconfig.
Signed-off-by: Petri Savolainen <petri.savolainen(a)linaro.org>
Reviewed-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/DEPENDENCIES b/DEPENDENCIES
index 10a9861c..d5214663 100644
--- a/DEPENDENCIES
+++ b/DEPENDENCIES
@@ -19,7 +19,13 @@ Prerequisites for building the OpenDataPlane (ODP) API
3. Required packages
- Libraries currently required to link: openssl, libatomic, libconfig
+ Libraries currently required to link: libconfig, openssl, libatomic
+
+ On Debian/Ubuntu systems:
+ $ sudo apt-get install libconfig-dev
+
+ On CentOS/RedHat/Fedora systems:
+ $ sudo yum install libconfig-devel
It is possible to build ODP without OpenSSL by passing flag
--without-openssl to configure script. However this will result in
-----------------------------------------------------------------------
Summary of changes:
DEPENDENCIES | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
hooks/post-receive
--