From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2BEFFA04B7; Mon, 7 Sep 2020 12:29:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D25071BEE1; Mon, 7 Sep 2020 12:29:45 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 4F9E629AC for ; Mon, 7 Sep 2020 12:29:44 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 95A585C0182; Mon, 7 Sep 2020 06:29:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 07 Sep 2020 06:29:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= content-transfer-encoding:content-type:cc:subject:from:to:date :message-id:in-reply-to; s=fm2; bh=LW4VwjGQEDIbmV/rZeJlbqbZGy2P5 rs9TJB7qgyW/vk=; b=UXr/Qb+F46kIg7mycaLDsbuEvZgtKeHuS9rbnOCnKZKfr NuaXUcmOHZfTw+9RHKc0y/BhIgBPqFClZyDH2uYdEeljwxpZ4JWwDLdDeiBLY6eV hZETuAgLAYuRZ1FgfJ0zE0EMiDg3yPOJX1tuZlNOiNNZATEDOnV/mOLL21l+btao SgDQFVdOnoa5FwLEpUxm45NA43gNEHfkeWSbqvo2zRA4jtbUl8P80JhXFhHooMZ+ 1DLYMaREJN04F2362+Yrho3QL7pvS79/pSUptHBqdEfjHuEDm3XbTNq30oI9Aouh kidWuD3CdiHnVWTFJUQ8W+EtazwAKnXTfw9tRddKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=LW4Vwj GQEDIbmV/rZeJlbqbZGy2P5rs9TJB7qgyW/vk=; b=oLbArdvYf7XkS4M3YiokIx tOY4NgA2Z6qxT8s7j9Hep10f7Zvh7NAoRm5QV9+4bgMxNzivXQ3WdjzVh+Ct16gz HHtDZOV6lflnzZi9MM/Vh8kCvPiiUlIqxFtJauNN6VcC9OVNecxskddx1MX0QjIL 1Wx0gW2GrTe6iGZQa2CxbFdX5dhyvmFrF8K8nzXsUsUdKtuzc4stcnXaQYV0hKjq lZuXboQTx1BwAMHmVO28PpQZnEkoI9UuZ4UjKGydl5MArFNeWGA+b54cZ3j85oc1 YXjbsmhPYVcLuUua9J8VuYlWIEYtIdj9A2avvfi9xwxeX4jEhduJFn4QXSwgxc6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehtddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepgfgtuffhvfffkfgjsehtqhertddttdejnecuhfhrohhmpedfvfhhohhmrghs ucfoohhnjhgrlhhonhdfuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepleetheehveethedtffevtdegtefhieeivdekvdehueffheejheek hfdttdeuvedtnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from localhost (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id F3B21328005E; Mon, 7 Sep 2020 06:29:41 -0400 (EDT) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: "Louise Kilheeney" , "John McNamara" , "Marko Kovacevic" From: "Thomas Monjalon" To: "Ciara Power" , Date: Mon, 07 Sep 2020 12:20:39 +0200 Message-Id: In-Reply-To: <20200903152717.42095-23-ciara.power@intel.com> Subject: Re: [dpdk-dev] [PATCH v3 22/37] doc: remove references to make in contributing guides X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu Sep 3, 2020 at 6:27 PM CEST, Ciara Power wrote: > --- a/doc/guides/contributing/coding_style.rst > +++ b/doc/guides/contributing/coding_style.rst > -DPDK supports being built in two different ways: > - > -* using ``make`` - or more specifically "GNU make", i.e. ``gmake`` on > FreeBSD > -* using the tools ``meson`` and ``ninja`` > +DPDK supports being built by using the tools ``meson`` and ``ninja`` We can simply say "DPDK *is* built". I will add a final dot at the end of the sentence. > Any new library or driver to be integrated into DPDK should support > being > -built with both systems. While building using ``make`` is a legacy > approach, and > -most build-system enhancements are being done using ``meson`` and > ``ninja`` > -there are no plans at this time to deprecate the legacy ``make`` build > system. > +built with this system. I think this paragraph does not make sense anymore. > -Therefore all new component additions should include both a > ``Makefile`` and a > -``meson.build`` file, and should be added to the component lists in > both the > -``Makefile`` and ``meson.build`` files in the relevant top-level > directory: > +Therefore all new component additions should include a ``meson.build`` > file, > +and should be added to the component lists in the ``meson.build`` files > in the > +relevant top-level directory: > either ``lib`` directory or a ``driver`` subdirectory. [...] > --- a/doc/guides/contributing/design.rst > +++ b/doc/guides/contributing/design.rst > When absolutely necessary, there are several ways to handle specific > code: > =20 > -* Use a ``#ifdef`` with the CONFIG option in the C code. > +* Use a ``#ifdef`` with a build definition macro in the C code. > This can be done when the differences are small and they can be embedded > in the same C file: > =20 > .. code-block:: c > @@ -32,30 +32,22 @@ When absolutely necessary, there are several ways to > handle specific code: > titi(); > #endif > =20 > -* Use the CONFIG option in the Makefile. This is done when the > differences are more significant. > - In this case, the code is split into two separate files that are > architecture or environment specific. > - This should only apply inside the EAL library. If removing this last item, there are no "several ways" anymore. I think we should keep it (reworded) because we still have files compiled depending on the target architecture. [...] > -Library Statistics > ------------------- > - > -Description > -~~~~~~~~~~~ > - > -This document describes the guidelines for DPDK library-level > statistics counter > -support. This includes guidelines for turning library statistics on and > off and > -requirements for preventing ABI changes when implementing statistics. I think the ABI part is still relevant. [...] > -Prevention of ABI changes due to library statistics support > -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - > -The layout of data structures and prototype of functions that are part > of the > -library API should not be affected by whether the collection of > statistics > -counters is turned on or off for the current library. In practical > terms, this > -means that space should always be allocated in the API data structures > for > -statistics counters and the statistics related API functions are always > built > -into the code, regardless of whether the statistics counter collection > is turned > -on or off for the current library. > - > -When the collection of statistics counters for the current library is > turned > -off, the counters retrieved through the statistics related API > functions should > -have a default value of zero.