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 C880CA0352; Mon, 14 Feb 2022 18:24:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A47A940DDA; Mon, 14 Feb 2022 18:24:39 +0100 (CET) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by mails.dpdk.org (Postfix) with ESMTP id 28A114067E for ; Mon, 14 Feb 2022 18:24:39 +0100 (CET) Received: by mail-pf1-f170.google.com with SMTP id i21so28902604pfd.13 for ; Mon, 14 Feb 2022 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dWLAF4JudezZo/L3JAN5bO5d+TEKNJuQxh4CudkQOUc=; b=fSUdJph04Y0V7X6QSGLpnUFMjOz3prLyKixaIh4kCbcJHdNiw1KiFTe3EmPaNIGTMf zkblNIjh9CKx8OFW9PYGT5cYdVI2HWGkK/DmpuewkaapFtIyKPUilmOlO3OcYdZUWcpw Iwvw4/iZN/5WNUlEEBhieH1sLsRY+vZR9XSXcGbc/d56cQRxb2cLv771NJLZrizC7MvW C3e3FYvkB6Rnky51JNw2JKwL8u/vfm+IHx+LZkmUjxEt4fyGOoG/RwAk9ONZLCoQvGqP LsaXczAHzA2dHcbtGYO+ib1QCK52wOoc7+6cjof+YMrg50tDDymVhEKa8orh+i7OBI97 PZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dWLAF4JudezZo/L3JAN5bO5d+TEKNJuQxh4CudkQOUc=; b=Ms7H4DAwz69gTk1e81f1cxddNCQ4QpXAA/17eHSxEoLwsKKsPnaIjuqPUpgtkkQyrX rlHhm1BPR5IZkbvMkS02mPiN2SUYWIkCi0Ww3ginsDJ/yNFXrAlE+etkXhOE8vMUixr/ +aO9pEepkXQc2FQg3g0Lc9Uz3FZhbs81wmXlFZUWNMmBff5+kB7gIZmqxWb4ItoOXffb bFCVqYFAkjfJQgKdzYQ5M/bPvZgVGQTfParZKSreaDcAw+0vYGWhBYTkew9UvuXVwCrB mumVUwUXWw1rGj4P6sfLHCCMtuaLz4m+r6r7bJ6eX5Eh6xkHBiuGH7ZAMXNPV/vV4jE8 uPnQ== X-Gm-Message-State: AOAM532RxO8d+fsQnwe2ouMeepfr5XMjR676TNPAyM6B2bDtTt+4J/eZ tLjmzpOFMw1COKLWVUaD4Myp1w== X-Google-Smtp-Source: ABdhPJyL5tup/tKqP/UT2QcVafhGywldqBVtTVSyR7MpfzOOrP2SVrb8gkwrgeO0j5qAma7WAniWxg== X-Received: by 2002:a05:6a00:804:: with SMTP id m4mr553332pfk.45.1644859478168; Mon, 14 Feb 2022 09:24:38 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id u18sm37799395pfk.14.2022.02.14.09.24.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 09:24:37 -0800 (PST) Date: Mon, 14 Feb 2022 09:24:35 -0800 From: Stephen Hemminger To: Bruce Richardson 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: <20220214092435.6fb6964e@hermes.local> In-Reply-To: References: <20220214091350.GA2793@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <3450334.eFTFzoEnKi@thomas> <3617079.VQhiAETyHQ@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 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.