From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C40EF2C2A for ; Wed, 28 Jun 2017 11:53:54 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 02:53:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,274,1496127600"; d="scan'208";a="120169551" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga006.fm.intel.com with ESMTP; 28 Jun 2017 02:53:52 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.26]) by irsmsx105.ger.corp.intel.com ([169.254.7.168]) with mapi id 14.03.0319.002; Wed, 28 Jun 2017 10:52:04 +0100 From: "Richardson, Bruce" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , "Stephen Hemminger" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v6 09/11] pci: implement find_device bus operation Thread-Index: AQHS72Be9D8IzdTbSUCbUVfRd76EDaI5TIgAgACiwgCAABo8oA== Date: Wed, 28 Jun 2017 09:52:04 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B072183ADB@IRSMSX104.ger.corp.intel.com> References: <5fe2e5fb2759d1f6d3f86e5dfae5c3fc177299da.1498577192.git.gaetan.rivet@6wind.com> <20170627163514.2ed2ec6b@xeon-e3> <20170628091746.GG13355@bidouze.vm.6wind.com> In-Reply-To: <20170628091746.GG13355@bidouze.vm.6wind.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjk3OGY2YjItYzY2ZC00NjYwLWEwODctOWRhZGRhYmQwNDFkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkE0eXhWcHM3c3ZTbkVEUmJHWkxPV015cEc1T2lXQ3Y1ZjdjK0YxcHJ1THc9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 09/11] pci: implement find_device bus operation 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: Wed, 28 Jun 2017 09:53:55 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ga=EBtan Rivet > Sent: Wednesday, June 28, 2017 10:18 AM > To: Stephen Hemminger > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 09/11] pci: implement find_device bus > operation >=20 > On Tue, Jun 27, 2017 at 04:35:14PM -0700, Stephen Hemminger wrote: > > On Tue, 27 Jun 2017 18:11:16 +0200 > > Gaetan Rivet wrote: > > > > > + int start_found =3D !!(start =3D=3D NULL); > > > + > > > + FOREACH_DEVICE_ON_PCIBUS(dev) { > > > + if (!start_found) { > > > + if (&dev->device =3D=3D start) > > > + start_found =3D 1; > > > + continue; > > > + } > > > + if (cmp(&dev->device, data) =3D=3D 0) > > > + return &dev->device; > > > + } > > > + return NULL; > > > +} > > > + > > > > Why is start_found not a boolean? > > >=20 > Ah, yes, I wrote this a few times over in rte_bus and rte_vdev, and mostl= y > used the same scheme in the PCI implementation, without checking for the > use of stdbool in the vincinity otherwise. >=20 > I would not be opposed to using a bool if I was rewriting it, but I don't > feel this change warrants a new version. >=20 > > Do you really need start_found at all? Why not just reuse existing > > pointer? > > >=20 > You are right, it could be reduced. But I find it a little too "clever" > in a sense, and I prefer usually to avoid rewriting input parameters. If > this function had to be refactored later, the writer would need to be > careful about start having changed. The advantage of using one variable > less does not outweight this drawback I think. >=20 +1 for having an extra variable for clarity.