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 0A8CA4C8F for ; Fri, 10 May 2019 11:28:18 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 02:28:18 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.96]) by fmsmga004.fm.intel.com with SMTP; 10 May 2019 02:28:15 -0700 Received: by (sSMTP sendmail emulation); Fri, 10 May 2019 10:28:14 +0100 Date: Fri, 10 May 2019 10:28:14 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, "Hunt, David" , Hajkowski , john.mcnamara@intel.com, marko.kovacevic@intel.com Message-ID: <20190510092814.GA76@bricha3-MOBL.ger.corp.intel.com> References: <20190313192107.696-1-marcinx.hajkowski@intel.com> <2474197.K3lgESSsOM@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2474197.K3lgESSsOM@xps> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API 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: Fri, 10 May 2019 09:28:19 -0000 On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote: > > > From: Marcin Hajkowski > > > > > > Function rte_power_set_env will no longer return > > > success on attempt to set env in initialized state. > > > > > > Signed-off-by: Marcin Hajkowski > > > > Acked-by: David Hunt > > Any other comment about this deprecation notice? > Seems ok to me, though the actual text is maybe a little unclear. It implies that the function will always return -1 unless the variable is unset when the function terminates (which seems to imply a failure case). What I presume is meant is that we have three possibilities: * The variable is set by the function -> return 0 * The varaible is already set, so no action needed -> return -1 (and set rte_errno to EEXIST or EALREADY??) * Setting the variable failed -> return -1 (and set rte_errno to ??) Is my understanding correct? Can the deprecation notice be improved to make it clear that only the middle case is the one being changed, e.g. by adding "in this case" to the second sentence. It might also be worthwhile calling out what the errno value will be to identify this failure vs regular failures. /Bruce PS: For this case, is there a reason to make it an error? Would a +1 value not also do, so anything non-zero implies no work done, and anything >=0 means that the value is set? Call set on something already set doesn't really seem like an error case to me. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 90D7BA0096 for ; Fri, 10 May 2019 11:28:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4B1C94CA7; Fri, 10 May 2019 11:28:20 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0A8CA4C8F for ; Fri, 10 May 2019 11:28:18 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 02:28:18 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.96]) by fmsmga004.fm.intel.com with SMTP; 10 May 2019 02:28:15 -0700 Received: by (sSMTP sendmail emulation); Fri, 10 May 2019 10:28:14 +0100 Date: Fri, 10 May 2019 10:28:14 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, "Hunt, David" , Hajkowski , john.mcnamara@intel.com, marko.kovacevic@intel.com Message-ID: <20190510092814.GA76@bricha3-MOBL.ger.corp.intel.com> References: <20190313192107.696-1-marcinx.hajkowski@intel.com> <2474197.K3lgESSsOM@xps> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <2474197.K3lgESSsOM@xps> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API 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" Message-ID: <20190510092814.cJO7v-t1fFQKp62bV5C65b0odxL3HDXHQhWlGfArOjE@z> On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote: > > > From: Marcin Hajkowski > > > > > > Function rte_power_set_env will no longer return > > > success on attempt to set env in initialized state. > > > > > > Signed-off-by: Marcin Hajkowski > > > > Acked-by: David Hunt > > Any other comment about this deprecation notice? > Seems ok to me, though the actual text is maybe a little unclear. It implies that the function will always return -1 unless the variable is unset when the function terminates (which seems to imply a failure case). What I presume is meant is that we have three possibilities: * The variable is set by the function -> return 0 * The varaible is already set, so no action needed -> return -1 (and set rte_errno to EEXIST or EALREADY??) * Setting the variable failed -> return -1 (and set rte_errno to ??) Is my understanding correct? Can the deprecation notice be improved to make it clear that only the middle case is the one being changed, e.g. by adding "in this case" to the second sentence. It might also be worthwhile calling out what the errno value will be to identify this failure vs regular failures. /Bruce PS: For this case, is there a reason to make it an error? Would a +1 value not also do, so anything non-zero implies no work done, and anything >=0 means that the value is set? Call set on something already set doesn't really seem like an error case to me.