From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 58FC0A0352; Mon, 14 Feb 2022 19:03:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED97E40DDA; Mon, 14 Feb 2022 19:03:34 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 2F52F4067E for ; Mon, 14 Feb 2022 19:03:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644861813; x=1676397813; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nbHzbZCIuLv02DEwqgFxbG79AJpCwCkviV/OVTxQr2Q=; b=AUJ9St8MXQTAxpLy7FE1adgtCCWJ5GiBFbPQOEzaLEBPo+A3mWx3pMFe n3ILHjlgAvrS+PVKp9I89fECpg2aKXB+5TiVn+i8a/FI0LQrYj6JpXTUh hlfJgXo7tsrt5mKlcCZx8tdAuD6GmwuX/FUEtadet7rMYeW2FeBbhXg+b 7EQo50TA+06nDV+N+tNjOzK0EkYQKeLyVFeCocLjGyHPVJtLPKv7MZz1d Q8zceVo01MUFLlSLL9Vbq4NHL/QjKa+c41uBAKk7U5wtyp2s+hhEkuIwm 4OkDU+HG3CwI8uanR9e26bWhHv0+UK89EBgN2pi48PrcA9xpEte6I5BJo g==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="237559982" X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="237559982" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 10:03:25 -0800 X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="543790884" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.13.94]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 14 Feb 2022 10:03:22 -0800 Date: Mon, 14 Feb 2022 18:03:17 +0000 From: Bruce Richardson To: Stephen Hemminger Cc: Thomas Monjalon , dev@dpdk.org, Tyler Retzlaff , ocardona@microsoft.com, roretzla@microsoft.com, david.marchand@redhat.com, ferruh.yigit@intel.com Subject: Re: out of tree driver builds broken with C++ Message-ID: References: <20220214091350.GA2793@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <3450334.eFTFzoEnKi@thomas> <3617079.VQhiAETyHQ@thomas> <20220214092435.6fb6964e@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220214092435.6fb6964e@hermes.local> X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Feb 14, 2022 at 09:24:35AM -0800, Stephen Hemminger wrote: > On Mon, 14 Feb 2022 15:03:43 +0000 > Bruce Richardson wrote: > > > On Mon, Feb 14, 2022 at 11:43:35AM +0000, Bruce Richardson wrote: > > > On Mon, Feb 14, 2022 at 12:19:24PM +0100, Thomas Monjalon wrote: > > > > 14/02/2022 11:45, Bruce Richardson: > > > > > On Mon, Feb 14, 2022 at 10:22:08AM +0100, Thomas Monjalon wrote: > > > > > > 14/02/2022 10:13, Tyler Retzlaff: > > > > > > > while the driver api is "internal" we agreed some time ago that drivers > > > > > > > could be built external to the dpdk tree. by enabling the meson setup > > > > > > > option -Denable_driver_sdk=true. > > > > > > > > > > > > > > it was agreed that the driver api was internal and would attract no > > > > > > > binary compatibility support which was fine. this change has now > > > > > > > imposed a further restriction that out of tree drivers have to be > > > > > > > authored in C only as non-C++ compatible code will invariably leak into > > > > > > > the internal structures. > > > > > > > > > > > > > > you won't allow us to build C++ drivers in the dpdk tree and it seems > > > > > > > now you are preventing building of C++ drivers outside of the tree too. > > > > > > > > > > > > That's the problem of non-written assumptions, they are unknown or forgotten. > > > > > > Did we agree to support out-of-tree drivers in C++? > > > > > > > > > > > > We really need to make things clear and written in documentation. > > > > > > > > > > > > > could we please re-evaluate this. > > > > > > > > > > > > Yes we can re-evaluate. > > > > > > What is the list of impacted files? > > > > > > > > > > > Hacking meson files a bit, the list of SDK header files is reported as below. > > > > > > > > > > /Bruce > > > > > > > > > > Message: SDK headers: > > > > > Message: ethdev_driver.h > > > > > Message: ethdev_pci.h > > > > > Message: ethdev_vdev.h > > > > > Message: cryptodev_pmd.h > > > > > Message: eventdev_pmd.h > > > > > Message: eventdev_pmd_pci.h > > > > > Message: eventdev_pmd_vdev.h > > > > > Message: eventdev_trace.h > > > > > Message: event_timer_adapter_pmd.h > > > > > Message: rte_dmadev_pmd.h > > > > > Message: vdpa_driver.h > > > > > > > > I see no harm in supporting C++ include of these headers. > > > > Any objection? > > > > > > > > Could we have a test in chkincs for the SDK headers? > > > > > > > Yes. It may make things a little more complicated, though, as it seems > > > these headers also have a tendency to rely on some driver headers - > > > specifically bus driver headers. > > > > > > > Working on a patch to add these to checks. However, just running a c++ > > compile does not check for valid 'extern "C"' blocks. Adding the following > > to chkincs/meson.build as a basic sanity check throws up a larger list of > > files to be looked at. > > > > Diff: > > > > +# check for extern C in files, since this is not detected as an error by the compiler > > +grep = find_program('grep', required: false) > > +if grep.found() > > + errlist = run_command([grep, '--files-without-match', '^extern "C"', dpdk_chkinc_headers], > > + check: true, capture: true).stdout().split() > > + if errlist != [] > > + error('Files missing C++ \'extern "C"\' guards:\n- ' + '\n- '.join(errlist)) > > + endif > > +endif > > + > > > > Output: > > ../buildtools/chkincs/meson.build:45:8: ERROR: Problem encountered: Files missing C++ 'extern "C"' guards: > > - /home/bruce/dpdk.org/lib/telemetry/rte_telemetry.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_bitops.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_branch_prediction.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_compat.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_hypervisor.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_keepalive.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_pci_dev_feature_defs.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_pci_dev_features.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_time.h > > - /home/bruce/dpdk.org/lib/eal/include/rte_trace_point_register.h > > - /home/bruce/dpdk.org/lib/eal/linux/include/rte_os.h > > - /home/bruce/dpdk.org/lib/ethdev/rte_dev_info.h > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_driver.h > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_pci.h > > - /home/bruce/dpdk.org/lib/ethdev/ethdev_vdev.h > > - /home/bruce/dpdk.org/lib/metrics/rte_metrics_telemetry.h > > - /home/bruce/dpdk.org/lib/acl/rte_acl_osdep.h > > - /home/bruce/dpdk.org/lib/bpf/bpf_def.h > > - /home/bruce/dpdk.org/lib/compressdev/rte_compressdev_internal.h > > - /home/bruce/dpdk.org/lib/cryptodev/cryptodev_pmd.h > > - /home/bruce/dpdk.org/lib/eventdev/rte_event_ring.h > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd.h > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd_pci.h > > - /home/bruce/dpdk.org/lib/eventdev/eventdev_pmd_vdev.h > > - /home/bruce/dpdk.org/lib/kni/rte_kni_common.h > > - /home/bruce/dpdk.org/lib/vhost/rte_vdpa.h > > - /home/bruce/dpdk.org/lib/vhost/rte_vhost_async.h > > - /home/bruce/dpdk.org/lib/vhost/rte_vhost_crypto.h > > - /home/bruce/dpdk.org/lib/vhost/vdpa_driver.h > > > > Regards, > > /Bruce > > The actual C++ guards are small and have no impact therefore we > should accept patches as needed. Having more guards than needed is > just noise. > > But the responsibility of telling DPDK project where they are required > should fall to any out-of-tree users who care. The guards in the above files are all needed, I believe. The scan for chkincs only runs on header files that are public, or part of the driver_sdk set. Internal headers aren't scanned and don't need the guards. /Bruce