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 F17BAA2E1B for ; Wed, 4 Sep 2019 21:58:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8105A1EB15; Wed, 4 Sep 2019 21:58:52 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 978651EAFE for ; Wed, 4 Sep 2019 21:58:51 +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-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BD35A4C0089; Wed, 4 Sep 2019 19:58:49 +0000 (UTC) Received: from [100.107.41.21] (188.170.82.248) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 4 Sep 2019 20:58:43 +0100 From: Andrew Rybchenko To: Thomas Monjalon CC: Ferruh Yigit , David Marchand , Date: Wed, 4 Sep 2019 22:58:39 +0300 Message-ID: <16cfddb8998.27dc.d74a604c1342fc6d922a87b3e5a1c1e3@solarflare.com> In-Reply-To: <2169155.oR67J0XmJ6@xps> References: <1566214919-32250-1-git-send-email-david.marchand@redhat.com> <3044851.BoT7FmBCyV@xps> <87c65c82-87c8-374d-1b62-36e5bd02335a@solarflare.com> <2169155.oR67J0XmJ6@xps> User-Agent: AquaMail/1.20.0-1469 (build: 102100004) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Originating-IP: [188.170.82.248] 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-24888.003 X-TM-AS-Result: No-14.025500-8.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1ii6/VcDv9f0HDfixW9O5cY6VTG9cZxEjLk1kyQDpEj8BOi /sYgPshRGUBcLOUp4UPeVhO3jGJTymm3SnkbLZr6+CjwEqX1p7k4eGohd7gjNoxRWJphhsrcrL/ dYc9oKZXWBSRaCrpJblYF3d4K8t2ki40n6jP10twmEURBmKrZlEyQ5fRSh2654w7R7P4I0tIH1L bWLCmuiH+jR0pZfgdcqpZqVcyBRv05HWa1kxc3MWzBijri5+RVtlX8GfOXuDgz91mDYZLM5YdaY X5m6/4YJbgOoiEqV97O9GIXQI4vS9fwCYFktIJNolVO7uyOCDWIWGvfT9ZpjMK0HkBcZFjbAmdY 1rZm0EiITv8mSIB6yH8mA3sDDq0AjWvNg9povs9oFT3KzpHqE9RnEQCUU+jzjoczmuoPCq0As8B zKaJqsJ0GjuvC9uwRhmQszyOxYkPIlhxhP4ZZpI+FUppmeXmV X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.025500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24888.003 X-MDID: 1567627130-iSFrO2yzeZtK Subject: Re: [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers 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 September 4, 2019 22:42:12 Thomas Monjalon wrote: > 04/09/2019 21:21, Andrew Rybchenko: >> On 9/4/19 8:45 PM, Thomas Monjalon wrote: >>> 03/09/2019 10:47, Ferruh Yigit: >>>> On 9/3/2019 9:06 AM, David Marchand wrote: >>>>> On Mon, Sep 2, 2019 at 4:29 PM Ferruh Yigit wrote: >>>>>> On 8/19/2019 12:41 PM, David Marchand wrote: >>>>>>> The function rte_log_register_type_and_pick_level() fills a gap for >>>>>>> dynamically loaded code (especially drivers) who would not pick up >>>>>>> the log level passed at startup. >>>>>>> >>>>>>> >>>>>>> Let's promote it to stable and export it for use by drivers via >>>>>>> a wrapper. >>>>>>> >>>>>>> >>>>>>> Signed-off-by: David Marchand >>>>>>> --- >>> [...] >>>>>>> /** >>>>>>> - * @warning >>>>>>> - * @b EXPERIMENTAL: this API may change without prior notice >>>>>>> - * >>>>>>> * Register a dynamic log type and try to pick its level from EAL options >>> [...] >>>>>>> -__rte_experimental >>>>>>> int rte_log_register_type_and_pick_level(const char *name, uint32_t level_def); >>>>>> +1 to remove experimental from the API. >>> I am not sure about this function API. >>> Why we combined register and level setting in one function? >> >> See [1] >> >> [1] http://git.dpdk.org/dpdk/commit/?id=b22e77c026 > > Sorry, it does not explain why we mix both operations in one function. Exactly to have one function instead of repeating two function calls everywhere. Log level should be set when log type is registered. Yes, it is possible to factor out a function just to pick log level, but I'm not sure it makes sense separately. In fact may be it makes sense to substitute just register with this one (I.e. remove simple register from piblic API and do not highlight that level is picked up in function name).