<div dir="ltr">Hi Ferruh,<div><br></div><div>I will work with Stephen on this. For the tone of the list, I believe we can try different ways to make the tone more friendly, while still being concise.<br><br>What about something like this:<br><li>Avoid including unused headers (process-iwyu.py).</li><li>Keep compiler warnings enabled in the build file.</li><li>Instead of using #ifdef with driver-specific macros, opt for runtime configuration.</li><li>Document device parameters in the driver guide.</li><li>Make device operations structs 'const'.</li><li>Use dynamic logging.</li><li>Skip DPDK version checks (RTE_VERSION_NUM) in the upstream code.</li><li>Add SPDX license tags and copyright notices on all sides.</li><li>Don’t introduce public APIs directly from the driver.<br><br>It's slightly more friendly.<br><br>Let me know what you think, I'm open to trying another way.</li></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2024 at 5:16 PM Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com">ferruh.yigit@amd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/10/2024 3:58 PM, Nandini Persad wrote:<br>
> This document was created to assist contributors<br>
> in creating DPDK drivers, providing suggestions<br>
> and guidelines for how to upstream effectively.<br>
> <br>
<br>
There are minor differences in this v3 and v2, isn't this version on top<br>
of v2, can those changes be from Stephen?<br>
<br>
<...><br>
<br>
> +<br>
> +Additional Suggestions<br>
> +----------------------<br>
> +<br>
> +* We recommend using DPDK macros instead of inventing new ones in the PMD.<br>
> +* Do not include unused headers (process-iwyu.py).<br>
> +* Do not disable compiler warning in the build file.<br>
> +* Do not use #ifdef with driver-defined macros, instead prefer runtime configuration.<br>
> +* Document device parameters in the driver guide.<br>
> +* Make device operations struct 'const'.<br>
> +* Use dynamic logging.<br>
> +* Do not use DPDK version checks (via RTE_VERSION_NUM) in the upstream code.<br>
> +* Be sure to have SPDX license tags and copyright notice on each side.<br>
> +* Do not introduce public Apis directly from the driver.<br>
><br>
<br>
API (Application Programming Interface) is an acronym and should be all<br>
uppercase, like 'APIs'.<br>
<br>
Overall the language in this list is imperative, I think it helps to<br>
make it simple, but I am not sure about the tone, I wonder if we can do<br>
better, do you have any suggestions?<br>
<br>
<br>
> +<br>
> +<br>
> +Dependencies<br>
> +------------<br>
> +<br>
> +At times, drivers may have dependencies to external software.<br>
> +For driver dependencies, same DPDK rules for dependencies applies.<br>
> +Dependencies should be publicly and freely available to<br>
> +upstream the driver.<br>
> +<br>
> +<br>
> +Test Tools<br>
> +----------<br>
> +<br>
> +Per patch in a patch series, be sure to use the proper test tools.<br>
> +<br>
> +* checkpatches.sh<br>
> +* check-git-log.sh<br>
> +* check-meson.py<br>
> +* check-doc-vs-code.sh<br>
> +* check-spdx-tag.sh<br>
><br>
<br>
`check-spdx-tag.sh` seems moved in v2 to "additional suggestions", I am<br>
for keeping it here, as "additional suggestions" are more things to take<br>
into consideration during design/development, above are actual scripts<br>
that we can use to verify code.<br>
<br>
And long term intention was to move this "tools to run list" to a more<br>
generic documentation, as these are not really specific to new PMD<br>
guide, but "additional suggestions" will stay in this document.<br>
<br>
</blockquote></div>