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