From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 431CFA0096 for ; Thu, 6 Jun 2019 15:19:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 15BE71B95A; Thu, 6 Jun 2019 15:19:27 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 17D381B958 for ; Thu, 6 Jun 2019 15:19:24 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2019 06:19:24 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by fmsmga007.fm.intel.com with SMTP; 06 Jun 2019 06:19:22 -0700 Received: by (sSMTP sendmail emulation); Thu, 06 Jun 2019 14:19:21 +0100 Date: Thu, 6 Jun 2019 14:19:21 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20190606131921.GC1586@bricha3-MOBL.ger.corp.intel.com> References: <20190530212525.40370-1-bruce.richardson@intel.com> <20190530212525.40370-4-bruce.richardson@intel.com> <20190530165305.391e6af3@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190530165305.391e6af3@hermes.lan> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 3/8] raw/ioat: add register definition file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, May 30, 2019 at 04:53:05PM -0700, Stephen Hemminger wrote: > On Thu, 30 May 2019 22:25:20 +0100 > Bruce Richardson wrote: > > > + > > +#ifdef __cplusplus > > +extern "C" { > > +#endif > > + > > This a driver private file, why the C++ guard here? It's not just a private file, it's included in the regular driver .h file, as the inline functions there need access to the register definitions. As for whether the functions need to be inline, most of them are inline for performance reasons, and the one that I would consider suitable for moving to the driver is inline also so that the user does not need to link their application against the PMD in order to use the device. Having the header at compile-time, and then the driver loaded at runtime is sufficient. /Bruce