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: > > -* 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: > > .. code-block:: c > @@ -32,30 +32,22 @@ When absolutely necessary, there are several ways to > handle specific code: > titi(); > #endif > > -* 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.
