From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
David Marchand <david.marchand@redhat.com>, <dev@dpdk.org>,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers
Date: Thu, 5 Sep 2019 09:29:10 +0300 [thread overview]
Message-ID: <5b3f331c-4011-63bf-3f38-44b160a6be66@solarflare.com> (raw)
In-Reply-To: <4083300.tcgOVcdeWQ@xps>
On 9/4/19 11:44 PM, Thomas Monjalon wrote:
> 04/09/2019 21:58, Andrew Rybchenko:
>> On September 4, 2019 22:42:12 Thomas Monjalon <thomas@monjalon.net> 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 <ferruh.yigit@intel.com> 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 <david.marchand@redhat.com>
>>>>>>>>> ---
>>>>> [...]
>>>>>>>>> /**
>>>>>>>>> - * @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).
> Given that we use it in a macro, we could keep two separate functions
> for logtype register and minimum log level (note that "minimum" is
> currently a missing word in these functions).
> Anyway, we will always use the single macro in our libraries.
I don't understand why "minimum" is missing. It assigns level specified
for the pattern if it matches, or use level_def if no match. No level
comparison, last match wins. If "minimum" refers to minimum logged
level, it matches rte_log_set_level() which has no "minimum" as well
in neither name nor description. Moreover, EMERG is smaller than
DEBUG and if we treat log levels as numbers, it sets maximum level
which is logged.
There are two usages right now without a macro, but it is not that
important. What I'm trying to say is that rte_log_register() plus setting
default after register is too error prone. It is the source of the bug
which we tried to workaround introducing the function.
If user sets log level (using eal command-line options), no special
efforts should be required to assign it on register. So, I think register
should always do it. The function name is not ideal since it is highlights
details which are not really interesting. It is logging support details that
log levels may be set before log types registration.
if we accept DPDK-wide default, it makes level_def parameter
unnecessary and the functionality to pick level may be simply
moved to rte_log_register() (using helper internal function) and
I see no good reasons why we really need type-specific defaults.
next prev parent reply other threads:[~2019-09-05 6:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 11:41 [dpdk-dev] [PATCH 00/11] Fixing log levels for dynamically loaded drivers David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 01/11] log: fix plugin level restore with patterns David Marchand
2019-08-19 12:30 ` Andrew Rybchenko
2019-08-19 11:41 ` [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers David Marchand
2019-08-19 12:27 ` Andrew Rybchenko
2019-09-02 14:29 ` Ferruh Yigit
2019-09-03 8:06 ` David Marchand
2019-09-03 8:47 ` Ferruh Yigit
2019-09-04 17:45 ` Thomas Monjalon
2019-09-04 19:21 ` Andrew Rybchenko
2019-09-04 19:41 ` Thomas Monjalon
2019-09-04 19:58 ` Andrew Rybchenko
2019-09-04 20:44 ` Thomas Monjalon
2019-09-05 6:29 ` Andrew Rybchenko [this message]
2019-09-05 7:13 ` David Marchand
2019-09-05 7:45 ` Thomas Monjalon
2019-08-19 11:41 ` [dpdk-dev] [PATCH 03/11] drivers/baseband: use new logtype wrapper David Marchand
2019-08-19 15:39 ` Chautru, Nicolas
2019-08-19 11:41 ` [dpdk-dev] [PATCH 04/11] drivers/bus: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 05/11] drivers/common: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 06/11] drivers/compress: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 07/11] drivers/crypto: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 08/11] drivers/event: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 09/11] drivers/mempool: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 10/11] drivers/net: " David Marchand
2019-08-19 14:55 ` Legacy, Allain
2019-09-02 16:11 ` Ferruh Yigit
2019-09-03 8:06 ` David Marchand
2019-09-03 15:03 ` Stephen Hemminger
2019-08-19 11:41 ` [dpdk-dev] [PATCH 11/11] drivers/raw: " David Marchand
2019-09-02 14:17 ` [dpdk-dev] [PATCH 00/11] Fixing log levels for dynamically loaded drivers Ferruh Yigit
2019-09-03 8:06 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b3f331c-4011-63bf-3f38-44b160a6be66@solarflare.com \
--to=arybchenko@solarflare.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=olivier.matz@6wind.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).