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 0CA79A046B for ; Tue, 23 Jul 2019 16:52:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A0161C038; Tue, 23 Jul 2019 16:52:54 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 0A26F1C036 for ; Tue, 23 Jul 2019 16:52:52 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id AB930980084; Tue, 23 Jul 2019 14:52:51 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 15:52:46 +0100 To: Stephen Hemminger CC: Thomas Monjalon , Ferruh Yigit , References: <1563890871-26901-1-git-send-email-arybchenko@solarflare.com> <20190723073821.6cf51bcc@hermes.lan> From: Andrew Rybchenko Message-ID: <337d5e16-befa-1260-9993-2624669c68bf@solarflare.com> Date: Tue, 23 Jul 2019 17:52:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190723073821.6cf51bcc@hermes.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [85.187.13.152] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24788.000 X-TM-AS-Result: No-2.137600-8.000000-10 X-TMASE-MatchedRID: 9zTThWtzImvmLzc6AOD8DfHkpkyUphL9amDMhjMSdnk26TIMgH4dujxq aAlMCrJwULd14sEtBkEgiuCpII+8g3iIda1vG1h5GUlF/M3Dxp+UctRw0zzl2qsoAw12Y1UTeLX 1WZ155N4LEHSjNQo7alyMIWk37QrbBCG38Am/dr2Y4WcYQvQk45KLNrbpy/A0/sHppCbpB3fnU/ zlxreh3uLzNWBegCW2RYvisGWbbS+No+PRbWqfRK6NVEWSRWybRNb+DVW5Ko9+Xdu7C5Qihe/9q VoRvrum+aTPnYZrZJyNBt1VmPD/v9n3TXdhsbQEAuRou1LIhy943TyR8vslQE5vFClW/nXihXIC XPkDTMLvGyaLyWJvBWLqcdF40kDywzhVZiqhieGz597RaJ+lCg== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--2.137600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24788.000 X-MDID: 1563893572-Hq4PN80MP_sL Subject: Re: [dpdk-dev] [PATCH] doc: add deprecation notice to fix ethdev API returning void 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" On 7/23/19 5:38 PM, Stephen Hemminger wrote: > On Tue, 23 Jul 2019 15:07:51 +0100 > Andrew Rybchenko wrote: > >> void return value is bad for get API (like rte_eth_dev_info-get()) >> since caller does not know if the function does its job or not and >> output value is filled in. >> >> void return value is bad for state changing API (like >> rte_eth_promiscuous_enable()) since caller should use get API >> to understand if state is really changed. >> >> Signed-off-by: Andrew Rybchenko > > In general this is a good ide, but for some API's it is hard > to think of a way it would help. For example: > void return is ok for close routines because if close() returns > an error the application really has no choice about what to do. Yes, I agree. But application can always ignore return value. Long-long time ago it was a surprise to me that libc close() has non-void return value. I intentionally provided everything which makes sense to me to raise discussion. I was unsure in stop, close and owner delete functions.