| Message ID | 1452778191-26996-1-git-send-email-bill.fischofer@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On 14 January 2016 at 08:29, Bill Fischofer <bill.fischofer@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.fischofer@linaro.org> > Reviewed-by: Mike Holmes >mike.holmes@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
ping. v4 of this series has Mike's review and needs to be merged. Thanks. On Thu, Jan 14, 2016 at 12:57 PM, Mike Holmes <mike.holmes@linaro.org> wrote: > > > On 14 January 2016 at 08:29, Bill Fischofer <bill.fischofer@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.fischofer@linaro.org> >> > > Reviewed-by: Mike Holmes >mike.holmes@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 > > >
This should go into master I think, is there anything specific to API-NEXT ? On 25 January 2016 at 13:05, Bill Fischofer <bill.fischofer@linaro.org> wrote: > ping. v4 of this series has Mike's review and needs to be merged. Thanks. > > On Thu, Jan 14, 2016 at 12:57 PM, Mike Holmes <mike.holmes@linaro.org> > wrote: > >> >> >> On 14 January 2016 at 08:29, Bill Fischofer <bill.fischofer@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.fischofer@linaro.org> >>> >> >> Reviewed-by: Mike Holmes >mike.holmes@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 >> >> >> > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs "Work should be fun and collborative, the rest follows"
This was targeted at api-next, however it can be applied there and promoted to master as part of ODP v1.7 or before as needed. On Mon, Jan 25, 2016 at 1:34 PM, Mike Holmes <mike.holmes@linaro.org> wrote: > This should go into master I think, is there anything specific to API-NEXT > ? > > On 25 January 2016 at 13:05, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> ping. v4 of this series has Mike's review and needs to be merged. >> Thanks. >> >> On Thu, Jan 14, 2016 at 12:57 PM, Mike Holmes <mike.holmes@linaro.org> >> wrote: >> >>> >>> >>> On 14 January 2016 at 08:29, Bill Fischofer <bill.fischofer@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.fischofer@linaro.org> >>>> >>> >>> Reviewed-by: Mike Holmes >mike.holmes@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 >>> >>> >>> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > "Work should be fun and collborative, the rest follows" > > >
v5 was sent. It's better to continue discussion there. That changes will break pdf creation and everybody agree with it? Maxim. On 01/26/2016 00:03, Bill Fischofer wrote: > This was targeted at api-next, however it can be applied there and > promoted to master as part of ODP v1.7 or before as needed. > > On Mon, Jan 25, 2016 at 1:34 PM, Mike Holmes <mike.holmes@linaro.org > <mailto:mike.holmes@linaro.org>> wrote: > > This should go into master I think, is there anything specific to > API-NEXT ? > > On 25 January 2016 at 13:05, Bill Fischofer > <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> wrote: > > ping. v4 of this series has Mike's review and needs to be > merged. Thanks. > > On Thu, Jan 14, 2016 at 12:57 PM, Mike Holmes > <mike.holmes@linaro.org <mailto:mike.holmes@linaro.org>> wrote: > > > > On 14 January 2016 at 08:29, Bill Fischofer > <bill.fischofer@linaro.org > <mailto:bill.fischofer@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.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>> > > > Reviewed-by: Mike Holmes >mike.holmes@linaro.org > <mailto:mike.holmes@linaro.org>> > > --- > configure.ac <http://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 <http://configure.ac> > b/configure.ac <http://configure.ac> > index 4f89f03..5c10d7f 100644 > --- a/configure.ac <http://configure.ac> > +++ b/configure.ac <http://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 <mailto: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 > > > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/>***│ *Open source software for > ARM SoCs > "Work should be fun and collborative, the rest follows" > >
On 26 January 2016 at 06:25, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > v5 was sent. It's better to continue discussion there. > > That changes will break pdf creation and everybody agree with it? > Yes, I agree > > Maxim. > > > On 01/26/2016 00:03, Bill Fischofer wrote: > >> This was targeted at api-next, however it can be applied there and >> promoted to master as part of ODP v1.7 or before as needed. >> >> On Mon, Jan 25, 2016 at 1:34 PM, Mike Holmes <mike.holmes@linaro.org >> <mailto:mike.holmes@linaro.org>> wrote: >> >> This should go into master I think, is there anything specific to >> API-NEXT ? >> >> On 25 January 2016 at 13:05, Bill Fischofer >> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> wrote: >> >> ping. v4 of this series has Mike's review and needs to be >> merged. Thanks. >> >> On Thu, Jan 14, 2016 at 12:57 PM, Mike Holmes >> <mike.holmes@linaro.org <mailto:mike.holmes@linaro.org>> wrote: >> >> >> >> On 14 January 2016 at 08:29, Bill Fischofer >> <bill.fischofer@linaro.org >> <mailto:bill.fischofer@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.fischofer@linaro.org >> <mailto:bill.fischofer@linaro.org>> >> >> >> Reviewed-by: Mike Holmes >mike.holmes@linaro.org >> <mailto:mike.holmes@linaro.org>> >> >> --- >> configure.ac <http://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 <http://configure.ac> >> b/configure.ac <http://configure.ac> >> index 4f89f03..5c10d7f 100644 >> --- a/configure.ac <http://configure.ac> >> +++ b/configure.ac <http://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 <mailto: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 >> >> >> >> >> >> -- Mike Holmes >> Technical Manager - Linaro Networking Group >> Linaro.org <http://www.linaro.org/>***│ *Open source software for >> ARM SoCs >> "Work should be fun and collborative, the rest follows" >> >> >> > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs "Work shoudl be fun and collborative, the rest follows"
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
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.fischofer@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(-)