From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v8 20/24] x86: L2 CAT: implement set value flow. Date: Wed, 1 Mar 2017 12:31:59 +0100 Message-ID: <1488367919.5548.124.camel@citrix.com> References: <1487148579-7243-1-git-send-email-yi.y.sun@linux.intel.com> <1487148579-7243-21-git-send-email-yi.y.sun@linux.intel.com> <20170228152539.okk4xu7ghx54uioi@dhcp-3-221.uk.xensource.com> <20170301065942.GF30133@yi.y.sun> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1229167353558410693==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cj2UO-0005T3-JH for xen-devel@lists.xenproject.org; Wed, 01 Mar 2017 11:32:12 +0000 In-Reply-To: <20170301065942.GF30133@yi.y.sun> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Yi Sun , Roger Pau =?UTF-8?Q?Monn=EF=BF=BD?= Cc: kevin.tian@intel.com, wei.liu2@citrix.com, he.chen@linux.intel.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, mengxu@cis.upenn.edu, jbeulich@suse.com, chao.p.peng@linux.intel.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============1229167353558410693== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-pJwfuZtYLXgm1Rz08813" --=-pJwfuZtYLXgm1Rz08813 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-03-01 at 14:59 +0800, Yi Sun wrote: > On 17-02-28 15:25:39, Roger Pau Monn=EF=BF=BD wrote: > > The logic of this function is kind of weird IMHO, you seem to be > > able to return > > an error, and also a parameter that indicates success ("found"). > > Can't this be > > simplified to simply return an error code, and the found parameter > > removed? > >=C2=A0 > In find_cos(), compare_val() is called to check if there is already a > COS ID > that all features values are same as input. All features in list > should be > checked. The 'found' is used record the final result, if all features > values are > same as input value array. You can see, after traversal of feature > list, we > return the cos if found is true. >=20 So, you can, for instance, use different error values, and check for which one has been returned in the caller. Like, use ENOENT for 'invalid ID' as you're doing right now, and, say,=C2=A0ESRCH, for 'feature not found'. Is that right? > Of course, I can change the function to remove 'found' from the > parameter. > But is it so necessary? Thanks! >=20 It's hard to tell whether it is "so necessary", but I agree with Roger that it would improve the code. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-pJwfuZtYLXgm1Rz08813 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYtrEwAAoJEBZCeImluHPuIqYQAMg/yOnQaTrfylCTIp8CzYo5 z5lu0sJFyKGMFlhYTfjmaSIcyyYS9S1zc1okHtVu1FeU+VWDN7ytTOrRhmSgxT04 zRVTSUL8ZtBI6+cTvxSlyGO9Kj4GAcds2pQePBFVCYKGV1+VMtr5o5EQ1lmMhZk7 9O53mULUPOeX+JntVRMX9+x3N8cj6YUhkS/lAIrf09gnisQhYfbvIJbv2IRiBG2D FxCN8B1c10JwxIBKeG72H4qfExgvqmD2wVUj7a4bYasFVIrmnQEVqRjwv5YvqQsX X8Hgw1kMZNXZA1MKC7qOVHnfCmWW02TlTZ3G0wuRQEPIYAJy644pu+Rq02IVp3ld vg6ph46KKAx3u13JldyiDeHDhUi1pMaodkqci13l9nQS8fujjCxGlvUC9tO3fK94 HXRKsffop+AYrZ8HSA/f610QSOgCJqHIaRmwS8xJ9uZLMqW6TsSxfzqrDXq8p7g+ jcRoA7aCPjrpGJ8UlcTKtj80+wyi2TLzUmpW0oU6n5uP3LO1z1/OfLaZk8Tww3x/ 8FhhJUrv4HGp32UcBVD8LBJWExJcnQC+1hS83FLsAVqv+PKf6l7VnT3SgsMLjQ0y F/iwDfE3LBeNz6iYqkZyQIjXeJlqGhs6l0JOwn4XeCcdulr2Z6b0Qg0GZTNwflaU 65sViTO8T/zFYZHaerET =pxVy -----END PGP SIGNATURE----- --=-pJwfuZtYLXgm1Rz08813-- --===============1229167353558410693== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1229167353558410693==--