From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by dpdk.org (Postfix) with ESMTP id 4EA64B0A3 for ; Fri, 18 Apr 2014 15:32:20 +0200 (CEST) Received: by mail-we0-f180.google.com with SMTP id p61so1592767wes.11 for ; Fri, 18 Apr 2014 06:32:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=XWygOn6bVZF18Ng2TPGZaPQPscNgUaK6anaDXJCjzVs=; b=Hsxul2clCeqdQmR7D++Teri303I0VNLPT7QZckjtTQ+UvPg6fqFIYaUw6O8s356XA0 716ArxGtmckF8UvzpqnvljseY4pzQ2xgKVE8AwkXqye64CwAivuxv0EFMieVm92O/z4N fU4TasHNB0Pt1yBWNY90BIiOaQrLuY6MCCBYHCHERnukcw9Ps85WttvRzECusJKB8zi0 fsnYU58245B/X2QBM6AGoso9GxlPdRso0f3ur6oTBhqCcCdDm3emfVT24dYdk6BQFlNW gUGx+qJz7B7+VXPqDe7Ukk/zcHybS+/Lh5jBONmR0pnmjWnPafwdKELclba6XqJJJcZc Ww0g== X-Gm-Message-State: ALoCoQnbaRimgKNfQkrDBShaXTl99muUgoWoaIM72Q8lQQLwAb6h2GHCC2E9vYLWrTj9jGWvmuPv X-Received: by 10.181.13.137 with SMTP id ey9mr2457062wid.54.1397827937900; Fri, 18 Apr 2014 06:32:17 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id ph8sm43611718wjb.32.2014.04.18.06.32.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Apr 2014 06:32:17 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Fri, 18 Apr 2014 15:32:15 +0200 Message-ID: <2949761.MjI7H6hKpG@xps13> Organization: 6WIND User-Agent: KMail/4.12.4 (Linux/3.14.1-1-ARCH; KDE/4.12.4; x86_64; ; ) In-Reply-To: <20140418132054.GD4053@localhost.localdomain> References: <1397585169-14537-1-git-send-email-nhorman@tuxdriver.com> <1947585.TXBcrJqKvb@xps13> <20140418132054.GD4053@localhost.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 03/15] pmd: Add PMD_REGISTER_DRIVER macro X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:32:20 -0000 2014-04-18 09:20, Neil Horman: > On Fri, Apr 18, 2014 at 02:08:56PM +0200, Thomas Monjalon wrote: > > 2014-04-18 08:04, Neil Horman: > > > On Fri, Apr 18, 2014 at 04:42:01AM -0700, Thomas Monjalon wrote: > > > > 2014-04-15 14:05, Neil Horman: > > > > > Rather than have each driver have to remember to add a constructor > > > > > to it > > > > > to > > > > > make sure its gets registered properly, wrap that process up in a > > > > > macro > > > > > to > > > > > make registration a one line affair. This also sets the stage for > > > > > us to > > > > > make registration of vdev pmds and physical pmds a uniform process > > > > > > > > > > Signed-off-by: Neil Horman > > > > > > > > > > --- /dev/null > > > > > +++ b/lib/librte_eal/common/include/rte_pmd.h > > > > > > > > So you are creating a new header file for PMD API, right? > > > > > > > > According to rte_ethdev.h, > > > > "The Ethernet Device API is composed of two parts:" > > > > "- The application-oriented Ethernet API" > > > > "- The driver-oriented Ethernet API" > > > > > > > > So we should implement this macro in rte_ethdev.h. > > > > But maybe you prefer to split this file in two files. If so, please > > > > send a > > > > separated patch for that. > > > > > > Actually I'm fine with moving the macro to another file, though if I do, > > > I > > > think merging it into rte_dev.h is more appropriate, as thats where the > > > driver registration function lives. > > > > I'm not sure to understand what you're saying. > > My suggestion is to have 2 files in lib/librte_ether: 1 for application > > API > > and 1 for PMD API. > > I'm suggesting not having 2 files at all, and merging rte_pmd.h into into > rte_dev.h, which is where all the rest of the device registration code lives > already. Does that make sense? Oh yes, I didn't understand because you speak about rte_dev.h which is actually rte_ethdev.h. I'm fine with keeping it. I just was wondering if it would be a cleaner API by splitting it as it has 2 very different roles. -- Thomas