Thanks! On Fri, Aug 5, 2016 at 10:37 AM, Mike Holmes <[email protected]> wrote:
> Signed-off-by: Mike Holmes <[email protected]> > Reviewed-by: Bill Fischofer <[email protected]> > --- > doc/implementers-guide/implementers-guide.adoc | 26 > +++++++++++++------------- > 1 file changed, 13 insertions(+), 13 deletions(-) > > diff --git a/doc/implementers-guide/implementers-guide.adoc > b/doc/implementers-guide/implementers-guide.adoc > index 5c0e864..0e2edc0 100644 > --- a/doc/implementers-guide/implementers-guide.adoc > +++ b/doc/implementers-guide/implementers-guide.adoc > @@ -29,7 +29,7 @@ mapping of the ODP APIs to a specific target platform. > This is the focus of > this document. > > - A Validation Test Suite. This is an independent set of routines that > when > -run against an ODP implmenetation verifies that it correctly implements > all of > +run against an ODP implementation verifies that it correctly implements > all of > the defined ODP APIs at a functional level. The test suite is used by > implementers to self-certify their ODP implementation as well as by > third-parties to verify an implementation's claim to be ODP API compliant. > @@ -39,18 +39,18 @@ fully defined in the _ODP User's Guide_ > > === Organization of this Document > This document is designed to serve two purposes. Its larger purpose is to > -provide guidenace and practical advice for those wishing to implement ODP > on > +provide guidance and practical advice for those wishing to implement ODP > on > their platform. To help with this, as well as to provide deeper insight > into > how to think about ODP from an implementer's standpoint, this document > also > discusses in some depth the design and organization of a specific ODP > implementation: the odp-linux reference implementation distributed as > part of > the main ODP git repository. By grounding theory in practice and > discussing > a particular example implementation, it is hoped this will provide > insight into > -the tradeoffs implementers should consider in approaching how to best > implement > +the trade-offs implementers should consider in approaching how to best > implement > ODP on their platforms. > > The section <<include_structure>> discusses the layout of the ODP include > tree > -from an implementer's perspective. Although implementers have wide > lattitude > +from an implementer's perspective. Although implementers have wide > latitude > in how they organize their ODP implementations, it is recommended that > this > layout be be observed by other implementations. Doing so both simplifies > code > sharing with the odp-linux reference implementation and also ensure ease > of > @@ -637,7 +637,7 @@ It is recommended that however a platform wishes to > represent ODP abstract > types, that it do so in a strongly typed manner. Using strong types means > that an application that tries to pass a variable of type `odp_packet_t` > to > an API that expects an argument of type `odp_queue_t`, for example, will > result > -in a compililation error rather than some difficult to debug runtime > failure. > +in a compilation error rather than some difficult to debug runtime > failure. > > The *odp-linux* reference implementation defines all ODP abstract types > strongly > using a set of utility macros contained in > @@ -653,13 +653,13 @@ implementations choose typdefs and representations > that permit the > implementation to realize ODP APIs efficiently. This typically means that > the > handles defined by typedefs are either a pointer to an > implementation-defined > struct or else an index into an implementation-defined resource table. > The two > -LNG-provided ODP reference implemnetations illustrate both of these > approaches. > +LNG-provided ODP reference implementations illustrate both of these > approaches. > The *odp-dpdk* implementation follows the former approach (pointers) as > this > offers the highest performance. For example, in *odp-dpdk* an > `odp_packet_t` is a pointer to an `rte_mbuf` struct, which is how DPDK > represents packets. The *odp-linux* implementation, by contrast, uses > indices > as this permits more robust validation support while still being highly > -efficient. In general, software-based implemnetations will typically favor > +efficient. In general, software-based implementations will typically favor > pointers while hardware-based implementations will typically favor > indices. > > === ABI Considerations > @@ -670,13 +670,13 @@ portability guarantees provided by APIs to permit > binary portability as well. > > It is important to note that ODP neither defines nor prohibits the > specification > of ABIs. This is because ODP itself is an _Abstract API Specification_. As > -noted earlier, abstract APIs cannot be compiled in the absense of > completion > +noted earlier, abstract APIs cannot be compiled in the absence of > completion > by an implementation that instantiates them, so the question of ABIs is > really a question of representation agreement between multiple ODP > implementations. If two or more ODP implementations agree on things like > typedefs, endianness, alignments, etc., then they are defining an ABI > which > -would permit ODP applications compiled to that common set of instantations > -to interoperate at a binary as well as source level. > +would permit ODP applications compiled to that common set of > instantiations > +to inter operate at a binary as well as source level. > > ==== Traditional ABI > ABIs can be defined at two levels. The simplest ABI is within a specific > @@ -692,7 +692,7 @@ of typedefs, etc. so that the resulting output from > compilation is directly > executable on any platform that subscribes to that ABI. Adding a new > platform > in this approach simply requires that platform to accept the existing ABI > specification. Note that since the output of compilation in a traditional > ABI > -is a ISA-specific binary that applications cannot offer binary compability > +is a ISA-specific binary that applications cannot offer binary > compatibility > across platforms that use different ISAs. > > ==== Bitcode based ABI > @@ -716,9 +716,9 @@ library system selects the appropriate managed binary > for that target platform > and loads and runs it. > > Adding a new platform in this approach involves adding the definition for > that > -platform to the libary system so that a managed binary for it can be > created > +platform to the library system so that a managed binary for it can be > created > and deployed as needed. This occurs without developer involvement since > the > -bitcode format that is input to this backend process is indepentent of the > +bitcode format that is input to this backend process is independent of the > specific target platform. Note also that since bitcode is not tied to any > ISA, > applications using bitcode ABIs are binary portable between platforms > that use > different ISAs. This occurs without loss of efficiency because the > process of > -- > 2.7.4 > >
