From patchwork Thu May 12 16:29:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bill Fischofer X-Patchwork-Id: 67687 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp847262qge; Thu, 12 May 2016 09:32:00 -0700 (PDT) X-Received: by 10.140.105.71 with SMTP id b65mr10539290qgf.66.1463070720555; Thu, 12 May 2016 09:32:00 -0700 (PDT) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id 11si9013278qko.272.2016.05.12.09.32.00; Thu, 12 May 2016 09:32:00 -0700 (PDT) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 26A4E6164E; Thu, 12 May 2016 16:32:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 5C4AA6162C; Thu, 12 May 2016 16:31:27 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id AA18F61605; Thu, 12 May 2016 16:31:08 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by lists.linaro.org (Postfix) with ESMTPS id F3B9761655 for ; Thu, 12 May 2016 16:29:55 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id x19so128156343oix.2 for ; Thu, 12 May 2016 09:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=buj1PHVisogghMJszGbfUgQ6sqhkZl6evph7bbipR3k=; b=h+eDomrCsldhYOqjXZp7ufQ/YV2AtLMjkuM2JXONV732mBBM4b3OmtU9wpSloeBokN mYKGSSJgkBN9AmdpJjIqk975lxMzITY//5KGbfT6+JA0zMQW3CgXeEs3+zi2V8mvaVty XMaMHJO6MEiQD+JgIixDL1PqrWRur3fJ2vE8+VtHoxM2kmCI1HGcX9M6rhMf4T93kYRX i7QaZgCwXeR4e5NjGfe5glw0wwR5v6iI8kKYyQcx17idIWHD0X05TlNviFI7HEVO1Z2f MG8wXFLG+mItm1CuPHF0qGJNXm6ABaXdlha0Cy0niglT+cma06mk33rJ/zbg5bbXW7E2 jbog== X-Gm-Message-State: AOPr4FWunVFDuEpB0TsULbSvRgzpHPhgqquKTgmoToYvs3fn2+cdhsGSr7DstqNtZzvqA3Ziibk= X-Received: by 10.157.46.8 with SMTP id q8mr6173437otb.95.1463070595464; Thu, 12 May 2016 09:29:55 -0700 (PDT) Received: from localhost.localdomain (cpe-66-68-129-43.austin.res.rr.com. [66.68.129.43]) by smtp.gmail.com with ESMTPSA id tz3sm4056603obc.0.2016.05.12.09.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 May 2016 09:29:55 -0700 (PDT) From: Bill Fischofer To: lng-odp@lists.linaro.org Date: Thu, 12 May 2016 11:29:48 -0500 Message-Id: <1463070588-22987-2-git-send-email-bill.fischofer@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1463070588-22987-1-git-send-email-bill.fischofer@linaro.org> References: <1463070588-22987-1-git-send-email-bill.fischofer@linaro.org> MIME-Version: 1.0 X-Topics: patch Subject: [lng-odp] [PATCH 2/2] doc: guides: remove extraneous non-ascii characters from doc files X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" Suggested-by: Zoltan Kiss Signed-off-by: Bill Fischofer --- doc/application-api-guide/api_guide_lines.dox | 14 ++++++------ doc/process-guide/bylaws-guide.adoc | 16 +++++++------- doc/users-guide/users-guide-tm.adoc | 32 +++++++++++++-------------- 3 files changed, 31 insertions(+), 31 deletions(-) diff --git a/doc/application-api-guide/api_guide_lines.dox b/doc/application-api-guide/api_guide_lines.dox index c544afd..394e958 100644 --- a/doc/application-api-guide/api_guide_lines.dox +++ b/doc/application-api-guide/api_guide_lines.dox @@ -64,10 +64,10 @@ Minimizing pathlength in API design involves several considerations: ODP APIs MAY be implemented as preprocessor macros and/or inline functions. This is especially true for accessor functions that are designed to provide getters/setters for object meta data. - Limiting parameter validation and error-checking processing. - While useful for development and debugging, providing “bullet-proof” APIs that perform extensive parameter validation and error checking is often inappropriate. + While useful for development and debugging, providing "bullet-proof" APIs that perform extensive parameter validation and error checking is often inappropriate. While validations that can be performed statically at compile time or at little to no runtime cost SHOULD be considered, APIs MAY choose to leave behavior as undefined when presented with invalid parameters in the interest of runtime efficiency. -One of the reasons for using abstract types is to avoid having implementation knowledge “bleed through” the API, leading to possible parameter errors. +One of the reasons for using abstract types is to avoid having implementation knowledge "bleed through" the API, leading to possible parameter errors. When one API returns an opaque token to an application it is reasonable to expect that the application can pass that token to subsequent APIs without needing expensive runtime validation. ODP provides the helper APIs ODP_STATIC_ASSERT(cond,msg) and ODP_ASSERT(cond,msg) that SHOULD be used in implementations for performing appropriate validation. @@ -114,7 +114,7 @@ static inline odp_foo_t _odp_foo_from_bar(odp_bar_t bar) ODP APIs typically have prototypes of the form: @code -odp_return_type_t odp_api(p1_type p1, p2_type p2, …); +odp_return_type_t odp_api(p1_type p1, p2_type p2, ...); @endcode Where: @@ -134,7 +134,7 @@ This convention allows callers to easily determine success/failure of a call wit So, for example, an attempt to allocate a buffer from a buffer pool might return ODP_BUFFER_INVALID if the call was unsuccessful and errno could then be set to an appropriate reason (no storage available (ENOMEM, ENOBUFS), pool not recognized (EINVAL), etc.). In general APIs are free to define their own errno usage conventions and values or reuse standard errno values when appropriate. -When “standard” codes exist, implementations SHOULD make use of them so that standard utility functions like perror() can decode them intelligently. +When "standard" codes exist, implementations SHOULD make use of them so that standard utility functions like perror() can decode them intelligently. There are, however, a small set of standard codes that are commonly used. One errno value that MUST be present for all APIs is ODP_FUNCTION_NOT_AVAILABLE. This special reason code is used to indicate that the underlying implementation does not support the requested API, and SHOULD be equated to ENOSYS. @@ -168,8 +168,8 @@ When an interface is defined in a header file and is intended to to be reused in int start_of_function_scope; ... if (foo == bar) { - int start_of_block_scope; - ... + int start_of_block_scope; + ... } } @endcode @@ -195,7 +195,7 @@ At the same time, APIs SHOULD reflect essential needs of data plane application How to draw this line is a judgement call based on experience but API designers MUST take implementation practicalities into consideration when designing APIs to ensure that APIs and features can be implemented efficiently on a wide variety of underlying platforms. This is one of the reasons why some features MAY be defined as OPTIONAL. While allowed, the proliferation of OPTIONAL features SHOULD be avoided to enable broad application portability across many implementations. -At the same time, a “least common denominator” approach MUST NOT be taken as that defeats the purpose of providing higher-level abstractions in APIs. +At the same time, a "least common denominator" approach MUST NOT be taken as that defeats the purpose of providing higher-level abstractions in APIs. @subsection odp_deprecated ODP DEPRECATED A deprecated API will remain marked as such in the public API using #ODP_DEPRECATED for two release cycles for the #ODP_VERSION_API_MAJOR number. diff --git a/doc/process-guide/bylaws-guide.adoc b/doc/process-guide/bylaws-guide.adoc index 1c93968..434e16e 100644 --- a/doc/process-guide/bylaws-guide.adoc +++ b/doc/process-guide/bylaws-guide.adoc @@ -52,7 +52,7 @@ quality and review new patches to maintain that good quality. * When Maintainers accept code, they have to deal with it until they die or rip it out (so its important that they understand what the code does and why they need it). The contributor shall convince the maintainer to take their code (the -maintainer should feel like he would be stupid to not accept the code…) +maintainer should feel like he would be stupid to not accept the code) === Release Manager === @@ -65,7 +65,7 @@ Release. The roadmap shall state projected future releases and the expected content. == Steering Committee (SC) -* Defining the requirements for the project’s shared resources, email +* Defining the requirements for the project's shared resources, email lists and the homepage. * Speaking on behalf of the project. * Resolving license disputes regarding products of the project. @@ -76,24 +76,24 @@ content). === Patch approval Reviewed-by is only replied to the list after inspecting the code. If you have -review comments they should be constructive and not just saying “no”. +review comments they should be constructive and not just saying "no". Reviewed-by and Signed-off-by implies that you are co-responsible for any bugs found in the code. -If you don’t respond you are assumed to agree with the patch. +If you don't respond you are assumed to agree with the patch. == Voting == Voting is necessary if consensus not has been reached. Must have established quorum. -* “Yes”, “Agree”,"+1" the action should be performed. +* "Yes", "Agree","+1" the action should be performed. In general, this vote also indicates a willingness on the behalf of the voter in -“making it happen” +"making it happen" -* “Abstain” This vote indicates that the voter abstains. +* "Abstain" This vote indicates that the voter abstains. The voter has no interest or does not participate in the vote. -* “No”, “Disagree” "-1" the action should not be performed. +* "No", "Disagree" "-1" the action should not be performed. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an diff --git a/doc/users-guide/users-guide-tm.adoc b/doc/users-guide/users-guide-tm.adoc index 12685b2..1182cb2 100644 --- a/doc/users-guide/users-guide-tm.adoc +++ b/doc/users-guide/users-guide-tm.adoc @@ -271,9 +271,9 @@ result in faster operation and/or less memory used. odp_tm_params_init(&tm_params); // <1> tm_params.pktio = egress_pktio; - tm = odp_tm_create(“Example TM”, &tm_params); + tm = odp_tm_create("Example TM", &tm_params); -/* create 5 input queues here – two at priority 1 and three at priority 2. */ +/* create 5 input queues here - two at priority 1 and three at priority 2. */ odp_tm_queue_params_init(&queue_params); queue_params.priority = 1; @@ -287,7 +287,7 @@ result in faster operation and/or less memory used. odp_tm_node_params_init(&node_params); // <2> node_params.level = 1; - tm_node_1 = odp_tm_node_create(tm, “TmNode1”, &node_params); + tm_node_1 = odp_tm_node_create(tm, "TmNode1", &node_params); odp_tm_queue_connect(tmq_A1, tm_node_1); // <3> odp_tm_queue_connect(tmq_B1, tm_node_1); @@ -303,13 +303,13 @@ of common scheduler parameters. NOTE that this uses some pseudocode below instead of real C code so as to be more concise. */ odp_tm_sched_params_init(&sched_params); // <4> - sched_params.sched_modes = { ODP_TM_FRAME_BASED_WEIGHTS, … }; - sched_params.sched_weights = { 8, 8, 8, … }; - sched_profile_RR = odp_tm_sched_create(“SchedProfileRR”, &sched_params); + sched_params.sched_modes = { ODP_TM_FRAME_BASED_WEIGHTS, ... }; + sched_params.sched_weights = { 8, 8, 8, ... }; + sched_profile_RR = odp_tm_sched_create("SchedProfileRR", &sched_params); - sched_params.sched_modes = { ODP_TM_BYTE_BASED_WEIGHTS, … }; - sched_params.sched_weights = { 8, 8, 8, … }; - sched_profile_FQ = odp_tm_sched_create(“SchedProfileFQ”, &sched_params); + sched_params.sched_modes = { ODP_TM_BYTE_BASED_WEIGHTS, ... }; + sched_params.sched_weights = { 8, 8, 8, ... }; + sched_profile_FQ = odp_tm_sched_create("SchedProfileFQ", &sched_params); odp_tm_queue_sched_config(tm_node_1, tmq_A1, sched_profile_RR); // <5> odp_tm_queue_sched_config(tm_node_1, tmq_B1, sched_profile_RR); @@ -319,14 +319,14 @@ instead of real C code so as to be more concise. */ odp_tm_node_params_init(&node_params); // <6> node_params.level = 2; - tm_node_2 = odp_tm_node_create(tm, “TmNode2”, &node_params); + tm_node_2 = odp_tm_node_create(tm, "TmNode2", &node_params); odp_tm_node_connect(tm_node_1, tm_node_2); // <7> odp_tm_sched_params_init(&sched_params); // <8> - sched_params.sched_modes = { ODP_TM_BYTE_BASED_WEIGHTS, … }; - sched_params.sched_weights = { 8, 16, 24, … }; - sched_profile_WFQ = odp_tm_sched_create(“SchedProfileWFQ”, &sched_params); + sched_params.sched_modes = { ODP_TM_BYTE_BASED_WEIGHTS, ... }; + sched_params.sched_weights = { 8, 16, 24, ... }; + sched_profile_WFQ = odp_tm_sched_create("SchedProfileWFQ", &sched_params); odp_tm_node_sched_config(tm_node_2, tm_node_1, sched_profile_WFQ); // <9> ---- @@ -334,11 +334,11 @@ instead of real C code so as to be more concise. */ <1> Create a tm system, since that is a precursor to creating tm_queues. <2> Create a Node #1 <3> Connect the Queue(s) to the Node -> odp_tm_queue_connect() -<4> Create two sets of scheduler params – one implementing Round Robin (since -all weights are the same – namely 8) and the second implementing Fair Queuing. +<4> Create two sets of scheduler params - one implementing Round Robin (since +all weights are the same - namely 8) and the second implementing Fair Queuing. <5> Associate the Scheduler to the Node and the Queue(s) -> odp_tm_queue_sched_config() -Use the Round Robin profile for the priority 1 fan-in’s and Fair Queuing +Use the Round Robin profile for the priority 1 fan-ins and Fair Queuing for the priority 2 fan-ins. <6> Create a second Node #2