From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9847EA00C3; Thu, 14 May 2020 10:53:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 731881D6D1; Thu, 14 May 2020 10:53:29 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 332451D6CC for ; Thu, 14 May 2020 10:53:27 +0200 (CEST) IronPort-SDR: sUV+uEhAHJlD3QAL5D4sLW+1FNNFzX0zhZ4PTKF4tlx0ZH840RbUZLhylMKVxRyu4zt9+84NDe YCuW42XqCatg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2020 01:53:26 -0700 IronPort-SDR: p29e4sgfa5UckjA9DSRF2pLZT7AtQtcW7X5Cu0gvvBwx3bjeX++j5VA2MCR4OkA/V7HNtBl6E1 bXM7j3y00WUg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,390,1583222400"; d="scan'208";a="409998373" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 14 May 2020 01:53:26 -0700 Received: from hasmsx601.ger.corp.intel.com (10.184.107.141) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 14 May 2020 01:53:25 -0700 Received: from hasmsx603.ger.corp.intel.com (10.184.107.143) by HASMSX601.ger.corp.intel.com (10.184.107.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 14 May 2020 11:53:22 +0300 Received: from hasmsx603.ger.corp.intel.com ([10.184.107.143]) by HASMSX603.ger.corp.intel.com ([10.184.107.143]) with mapi id 15.01.1713.004; Thu, 14 May 2020 11:53:22 +0300 From: "Stojaczyk, Dariusz" To: Gaetan Rivet , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v1 2/2] pci: explain how empty strings are rejected in DBDF Thread-Index: AQHWKRQMvcuzdOYxYUCRG2RBNDETHqinSAKQ Date: Thu, 14 May 2020 08:53:22 +0000 Message-ID: References: <20200513104751.46466-1-grive@u256.net> <20200513104751.46466-3-grive@u256.net> In-Reply-To: <20200513104751.46466-3-grive@u256.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action x-originating-ip: [163.33.253.164] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v1 2/2] pci: explain how empty strings are rejected in DBDF 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" > -----Original Message----- > From: dev On Behalf Of Gaetan Rivet > Sent: Wednesday, May 13, 2020 12:48 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH v1 2/2] pci: explain how empty strings are rej= ected > in DBDF >=20 > Empty strings are forbidden as input to rte_pci_addr_parse(). > It is explicitly enforced in BDF parsing as parsing the bus > field will immediately fail. The related check is commented. >=20 > It is implicitly enforced in DBDF parsing, as the domain would be > parsed to 0 without error, but the check `end[0] !=3D ':'` afterward > will return -EINVAL. >=20 > Enforcing consistency between parsers by reading the code is not helped > by this property being implicit. Add a comment to explain. >=20 > Signed-off-by: Gaetan Rivet > --- Acked-by: Darek Stojaczyk