From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
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 <dev@dpdk.org>; Fri, 18 Apr 2014 15:32:20 +0200 (CEST)
Received: by mail-we0-f180.google.com with SMTP id p61so1592767wes.11
 for <dev@dpdk.org>; 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 <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 18 Apr 2014 06:32:17 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <nhorman@tuxdriver.com>
> > > > > 
> > > > > --- /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