From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 13F6E235 for ; Thu, 6 Jul 2017 12:10:11 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4677020BF6; Thu, 6 Jul 2017 06:10:11 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 06 Jul 2017 06:10:11 -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=WzqVddupjl6dP/L WOqPWz8potFxG/i1Rtr7js762kZY=; b=Fhvoss8KleDfWTv/Mh8CJ8xtwoVIGrC kABP0JxaLTF0o+rD3xF5xGLh2tYpk/romBs+WhyTulWhjzdpHGg+90RRrNBKYutP a7NRgh+VnnHULY3TC+7y3BgxbmuyQHs7jcdYbhXRl4pk4tqer4Qa7ZeuxYIMREa6 +LLMAwopv15c= 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=WzqVddupjl6dP/LWOqPWz8potFxG/i1Rtr7js762kZY=; b=q8gimxtW cHHyFZsRDJ63wLY9nXlcRvo9nXp8Eoa7YZL2PH1xS6QIaBrdMyr1PULySB2iN2IW r0BAFPWI87a/aZ2y5qWitDf0sQXNHrDu+GcnToMrtpJH97lwJ0irBItvxBpDNGH+ lvjl1by/HRK9+JyOcIrZ3jfTY3M/IbTSMncaDsmoy4dj5H3c6ij7MMpB5InGUsKG Pbw350MpQMfPCYiBWHqr+kQvCgNFAk2py22dMjH8ur5S1Zfo6Gs9SIHhQ7RY+Na5 dQQMxJnb+iW/gcOduCgwj5UbASE2ncS+tyAvNdcu3aZ+8s6aaEcTnz5fGNVmH5bZ rSXehBCt6jMksg== X-ME-Sender: X-Sasl-enc: +GltnUwSXix0wXc77Jr/MuUIa5KpNmRp6hYBW5ntFMHI 1499335810 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EBA1124251; Thu, 6 Jul 2017 06:10:10 -0400 (EDT) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet , Shreyansh Jain Cc: dev@dpdk.org Date: Thu, 06 Jul 2017 12:10:10 +0200 Message-ID: <2074223.j7Uj7OpmZu@xps> In-Reply-To: <20170705134521.GI11154@bidouze.vm.6wind.com> References: <20170705134521.GI11154@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH v7 5/6] 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, 06 Jul 2017 10:10:12 -0000 05/07/2017 15:45, Ga=EBtan Rivet: > On Wed, Jul 05, 2017 at 07:05:40PM +0530, Shreyansh Jain wrote: > > >+struct rte_bus * > > >+rte_bus_find_by_device_name(const char *str) > > >+{ > > >+ char name[32]; > >=20 > > It is possible to use a constant here? Basically, I am not sure why '32= ' has > > been chosen - or maybe, it might remind a reader in future the reason f= or > > this value. > >=20 > > Just to clarify: is there any documented limit on bus name? Until this > > point, the name (and length) of bus was responsibility of bus driver > > implementation. eal_common_bus.c doesn't codify any limit - so, this may > > have to be advertised, even if just within the code. >=20 > I agree that this is not clear. First thing however: this is a limit on > the device name length, not bus. >=20 > This problem is fixed in [1], as a single common device name location is > defined. The problem is that it is in another patchset (even if both are > closely linked and were only separated to ease integration). >=20 > This limit was currently taken from the arbitrary limit of device in > name in the original rte_devargs for virtual devices. I think it could > be exported as a define by rte_dev.h, used there and reused in [1] to > define the new rte_devargs structure. Please check this patch which was integrated yesterday: http://dpdk.org/commit/48d8675c9cf Now you can use RTE_DEV_NAME_MAX_LEN instead of hardcoded 32.