From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 11150374 for ; Thu, 29 Jun 2017 10:21:57 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 59424209AE; Thu, 29 Jun 2017 04:21:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 29 Jun 2017 04:21:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=jE3opaJT99Vozdq ftxD+XD4VamMtzGr6LgKFpb43M5s=; b=K+vu9tqH/zDze+NBZ+c5xMzuNkoJVAH JBBZv6JvI7eTKkUXbNfr4P/dpzIslhJ4yEA+bNF7u+Ke7QyvTwv6gL5i2TD1YT6h /bXHF5Ehve9UqMos9v+yOTKpr/hbRqX0BXdtRu3hPvY7TNT/eYvbkipN2XqafKPf FYBy8z9u+uKI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=jE3opaJT99VozdqftxD+XD4VamMtzGr6LgKFpb43M5s=; b=sGMrN0RQ twDoZuYR3Xy3XT6elMD5wLjAJzOJEPKBYOmja/18uzVB96xiqt129NTirx6OEk7t KnSkwtMt7VOXYS6I1zKzRjNi9RZ/OdlB1J/6aGDvKFPA9l67CidM2iaRMOnzji5W R7AzqMDWnjBuqZMWM4KMEmS0aBLQ5tzjDinfOFQAjMU0QqJ/Db2Y26GNaJUZzeCw 7UTbzkTsLI6TdUlSOBNzPSL0E+QOWM3yaKnYs6iYgjEUm8QbYXzA7BmpQGiKSiPc T1rxQIdkIUmuJSgo+byJGnORUXBdfCME7RBGH1K8RM7PSEJsf8Xa1BvWhWZdgMJh ITcxrba2oe9mUg== X-ME-Sender: X-Sasl-enc: HRaz+1pbQRBH/5OCwoltrgyfdFeOOFDvTnCzuJdVQ3Fv 1498724517 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A2B17E815; Thu, 29 Jun 2017 04:21:57 -0400 (EDT) From: Thomas Monjalon To: Jan Blunck Cc: dev@dpdk.org, Gaetan Rivet Date: Thu, 29 Jun 2017 10:21:56 +0200 Message-ID: <1847454.cyn7CixU0U@xps> In-Reply-To: References: <2359359.ae4fqFO3lF@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from a device name 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: , X-List-Received-Date: Thu, 29 Jun 2017 08:21:58 -0000 29/06/2017 09:56, Jan Blunck: > On Wed, Jun 28, 2017 at 7:03 PM, Thomas Monjalon wrote: > > 27/06/2017 20:55, Jan Blunck: > >> On Wed, Jun 21, 2017 at 1:30 AM, Gaetan Rivet wrote: > >> > /** > >> > + * Find a bus capable of identifying a device. > >> > + * > >> > + * @param str > >> > + * A device identifier (PCI address, virtual PMD name, ...). > >> > + * > >> > + * @return > >> > + * A valid bus handle if found. > >> > + * NULL if no bus is able to parse this device. > >> > + */ > >> > +struct rte_bus *rte_bus_from_dev(const char *str); > >> > >> I still don't agree with this. The bus name should be passed > >> explicitly by the user of the API. > >> > >> NAK. > > > > Please explain why you think the bus name should be explicit. > > If the bus is ambiguous, it can be explicited by the user. > > > > I see some good benefits in being tolerant with the bus/device > > representation. It provides a smooth transition to the bus model. > > > > We build libraries. The applications we build with the help of those > libraries get notified by the OS about device events. Those devices > are chields of their parent bus. At the time the event is fired the OS > already knows about: > > - the bus name (parent) > - the device name (child) > - additional event parameters (environment) > > Blame me that I probably spent too much time with Kay Sievers and > GregKH to understand that device naming is easy to get wrong. Just > look at the hyperv device names and how they switched to the UUID > scheme. I don't think that hyperv is the only bus that uses UUID as > device identification. We should not codify a policy of how to deduce > a bus name from a given device name if that is knowledge that is > already present externally. Otherwise I fear this part of the EAL will > be subject to constant churn. OK I understand your point that it is a weak identification. It is as weak as what we have currently. It works at least when we have only PCI and VDEV. However it does not prevent to use a strong identification with bus and parent names. I see rte_bus_from_dev() as a helper to transition to the new strong identification model. So we could remove it in few releases. Does it make sense?