On Wed, Mar 13, 2024 at 04:45:36PM -0700, Stephen Hemminger wrote: > On Fri, 2 Feb 2024 13:58:19 -0700 > Ashish Sadanandan <ashish.sadanan...@gmail.com> wrote: > > > > I think just having the extern "C" guard in all files is the safest > > > choice, > > > because it's immediately obvious in each and every file that it is > > > correct. > > > Taking the other option, to check any indirect include file you need to go > > > finding what other files include it and check there that a) they have > > > include guards and b) the include for the indirect header is contained > > > within it. > > > > > > Adopting the policy of putting the guard in each and every header is also > > > a > > > lot easier to do basic automated sanity checks on. If the file ends in .h, > > > we just use grep to quickly verify it's not missing the guards. > > > [Naturally, > > > we can do more complete checks than that if we want, but 99% percent of > > > misses can be picked up by a grep for the 'extern "C"' bit] > > > > > > /Bruce > > > > > > > 100% agree with Bruce. It's a valid ideological argument that private > > headers > > don't need such safeguards, but it's difficult to enforce and easy to break > > during refactoring. > > > > - Ashish > > But splashing this across all the internal driver headers is bad idea. > It should only apply to header files that exported in final package.
while we don't provide api/abi stability promises for driver headers we do optionally install them with -Denable_driver_sdk=true. the driver sdk allows drivers to be developed outside of the dpdk source tree, many such drivers are explicitly authored in C++ and are outside of the dpdk source tree because dpdk does not allow C++ drivers in tree.
