On 14 January 2016 at 08:29, Bill Fischofer <bill.fischo...@linaro.org>
wrote:
> Simplify ODP documentation builds by using .svg files directly for all
> images. This eliminates the need to create .png and .eps files via the
> imagemagic package. Note that this removes easy PDF output for ODP user
> documents, however there is no real demand for such capability.
>
> Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org>
>
Reviewed-by: Mike Holmes >mike.hol...@linaro.org>
> ---
> configure.ac | 10 ---------
> doc/images/.gitignore | 3 +--
> doc/images/Makefile.am | 39
> ++++++------------------------------
> doc/odp.dox | 2 +-
> doc/process-guide/release-guide.adoc | 4 ++--
> doc/users-guide/users-guide.adoc | 18 ++++++++---------
> 6 files changed, 19 insertions(+), 57 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 4f89f03..5c10d7f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -262,16 +262,6 @@ AC_ARG_ENABLE([user-guides],
> AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
>
> ##########################################################################
> -# Check for imagemagic availability
> -##########################################################################
> - AC_CHECK_PROGS([IMAGEMAGIC], [convert])
> - if test -z "$IMAGEMAGIC";
> - then AC_MSG_WARN([Imagemagic (convert) not found - continuing
> without image support])
> - fi
> -
> -AM_CONDITIONAL([HAVE_IMAGEMAGIC], [test "x${IMAGEMAGIC}" = "xconvert"])
> -
> -##########################################################################
> # Check for mscgen availability
> ##########################################################################
> AC_CHECK_PROGS([MSCGEN], [mscgen])
> diff --git a/doc/images/.gitignore b/doc/images/.gitignore
> index 148f2f2..1647e41 100644
> --- a/doc/images/.gitignore
> +++ b/doc/images/.gitignore
> @@ -1,2 +1 @@
> -*.png
> -*.eps
> +resource_management.svg
> diff --git a/doc/images/Makefile.am b/doc/images/Makefile.am
> index 8ab03b4..8fb8a99 100644
> --- a/doc/images/Makefile.am
> +++ b/doc/images/Makefile.am
> @@ -1,43 +1,16 @@
> -.svg.png:
> - convert $^ $@
> -
> -.svg.eps:
> - convert $^ $@
> -
> -.msc.png:
> - mscgen -T png -i $^ -o $@
> -
> -SVG_SRCS = \
> - atomic_queue.svg \
> - ordered_queue.svg \
> - parallel_queue.svg \
> - odp_components.svg \
> - odp_rx_processing.svg \
> - odp_scheduling.svg \
> - odp_traffic_manager.svg \
> - overview.svg \
> - release_git.svg \
> - simple_release_git.svg
> -
> -SVG_TARGETS = $(SVG_SRCS:svg=png)
> -SVG_TARGETS += $(SVG_SRCS:svg=eps)
> +.msc.svg:
> + mscgen -T svg -i $^ -o $@
>
> MSG_SRCS = resource_management.msc
> -MSG_TARGETS = $(MSG_SRCS:msc=png)
> +MSG_TARGETS = $(MSG_SRCS:msc=svg)
>
> -EXTRA_DIST = $(SVG_SRCS) $(MSG_SRCS)
> -
> -TARGETS=$(SVG_TARGETS) $(MSG_TARGETS)
> -
> -if HAVE_IMAGEMAGIC
> -TARGETS += $(SVG_TARGETS)
> -endif
> +EXTRA_DIST = $(MSG_SRCS)
>
> if HAVE_MSCGEN
> -TARGETS += $(MSG_TARGETS)
> +TARGETS = $(MSG_TARGETS)
> endif
>
> all-local: $(TARGETS)
>
> clean-local:
> - rm -f $(SVG_TARGETS) $(MSG_TARGETS)
> + rm -f $(MSG_TARGETS)
> diff --git a/doc/odp.dox b/doc/odp.dox
> index 0bff5ad..5792179 100644
> --- a/doc/odp.dox
> +++ b/doc/odp.dox
> @@ -17,7 +17,7 @@
> * also be useful for those wishing to implement ODP on other
> * platforms.
> *
> - * @image html overview.png
> + * @image html overview.svg
> *
> * ODP consists of a common layer and an implementation layer.
> * Applications written to the common layer are portable across all
> diff --git a/doc/process-guide/release-guide.adoc
> b/doc/process-guide/release-guide.adoc
> index 5bef890..302e058 100644
> --- a/doc/process-guide/release-guide.adoc
> +++ b/doc/process-guide/release-guide.adoc
> @@ -31,7 +31,7 @@ where a major release is to be made and applied
> atomically, this flow can be
> seen in Figure 1.
>
> .Overview of the ODP git process
> -image::../images/simple_release_git.png[align="center"]
> +image::../images/simple_release_git.svg[align="center"]
>
> Regular bug fixes, and implementation changes occur directly to master.
>
> @@ -46,7 +46,7 @@ cherry picked work so that it may be applied to master
> on release day, this can
> be seen in detail in Figure 2.
>
> .Overview of the ODP git process
> -image::../images/release_git.png[align="center"]
> +image::../images/release_git.svg[align="center"]
>
> === api-next ===
> acceptance criteria for patches to api-next (path 1):
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 6f7dd86..45fe4a8 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -12,7 +12,7 @@ Further details about ODP may be found at the
> http://opendataplane.org[ODP]
> home page.
>
> .Overview of a system running ODP applications
> -image::../images/overview.png[align="center"]
> +image::../images/overview.svg[align="center"]
>
> ODP is an API specification that allows many implementations to provide
> platform independence, automatic hardware acceleration and CPU scaling to
> @@ -22,7 +22,7 @@ write an application that can successfully take
> advantage of the API.
> :numbered:
> == Introduction
> .OpenDataPlane Components
> -image::../images/odp_components.png[align="center"]
> +image::../images/odp_components.svg[align="center"]
>
> .The ODP API Specification
> ODP consists of three separate but related component parts. First, ODP is
> an
> @@ -360,7 +360,7 @@ The *Classifier* provides a suite of APIs that control
> packet receive (RX)
> processing.
>
> .ODP Receive Processing with Classifier
> -image::../images/odp_rx_processing.png[align="center"]
> +image::../images/odp_rx_processing.svg[align="center"]
>
> The classifier provides two logically related services:
> [horizontal]
> @@ -397,7 +397,7 @@ The *Scheduler* provides a suite of APIs that control
> scalable event
> processing.
>
> .ODP Scheduler and Event Processing
> -image::../images/odp_scheduling.png[align="center"]
> +image::../images/odp_scheduling.svg[align="center"]
>
> The Scheduler is responsible for selecting and dispatching one or more
> events
> to a requesting thread. Event selection is based on several factors
> involving
> @@ -429,7 +429,7 @@ The *Traffic Manager* provides a suite of APIs that
> control traffic shaping and
> Quality of Service (QoS) processing for packet output.
>
> .ODP Transmit processing with Traffic Manager
> -image::../images/odp_traffic_manager.png[align="center"]
> +image::../images/odp_traffic_manager.svg[align="center"]
>
> The final stage of packet processing is to transmit it. Here,
> applications have
> several choices. As with RX processing, applications may send packets
> @@ -508,7 +508,7 @@ Shutdown is the logical reverse of the initialization
> procedure, with
> called to terminate ODP.
>
> .ODP Application Structure Flow Diagram
> -image::../images/resource_management.png[align="center"]
> +image::../images/resource_management.svg[align="center"]
>
> == Common Conventions
> Many ODP APIs share common conventions regarding their arguments and
> return
> @@ -636,7 +636,7 @@ SCHED queues that specify a sync mode of
> ODP_SCHED_SYNC_NONE are unrestricted
> in how events are processed.
>
> .Parallel Queue Scheduling
> -image::../images/parallel_queue.png[align="center"]
> +image::../images/parallel_queue.svg[align="center"]
>
> All events held on parallel queues are eligible to be scheduled
> simultaneously
> and any required synchronization between them is the responsibility of the
> @@ -658,7 +658,7 @@ more events from the same atomic queue if
> *odp_schedule_multi()* is used. In
> this case these multiple events all share the same atomic scheduling
> context.
>
> .Atomic Queue Scheduling
> -image::../images/atomic_queue.png[align="center"]
> +image::../images/atomic_queue.svg[align="center"]
>
> In this example, no matter how many events may be held in an atomic queue,
> only one calling thread can receive scheduled events from it at a time.
> Here
> @@ -678,7 +678,7 @@ scaleabilty of parallel queues, with the easy
> synchronization of atomic
> queues.
>
> .Ordered Queue Scheduling
> -image::../images/ordered_queue.png[align="center"]
> +image::../images/ordered_queue.svg[align="center"]
>
> When scheduling events from an ordered queue, the scheduler dispatches
> multiple
> events from the queue in parallel to different threads, however the
> scheduler
> --
> 2.5.0
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
