From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: "thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH v2] eal: redefine logtype values
Date: Thu, 13 Apr 2017 08:32:19 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D897478096D4@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20170412212347.0cd1966d@neon>
Hi Olivier,
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, April 12, 2017 8:24 PM
> To: De Lara Guarch, Pablo
> Cc: thomas.monjalon@6wind.com; dev@dpdk.org
> Subject: Re: [PATCH v2] eal: redefine logtype values
>
> Hi Pablo,
>
>
> On Wed, 12 Apr 2017 16:35:32 +0100
> Pablo de Lara <pablo.de.lara.guarch@intel.com> wrote:
...
>
>
> Thanks for spotting this issue. I think there is still a problem with
> the deprecated functions for which we want to keep compat:
>
> /* Set global log type */
> __rte_deprecated void
> rte_set_log_type(uint32_t type, int enable)
> {
> if (type < RTE_LOGTYPE_FIRST_EXT_ID) {
> if (enable)
> rte_logs.type |= type;
> else
> rte_logs.type &= ~type;
> }
>
> if (enable)
> rte_log_set_level(type, 0);
> else
> rte_log_set_level(type, RTE_LOG_DEBUG);
> }
>
> /* Get global log type */
> __rte_deprecated uint32_t
> rte_get_log_type(void)
> {
> return rte_logs.type;
> }
>
>
> There is a problem in these functions because they expect bitmasks
> for the first part.
>
> I does not look so easy to both fix the issue and keep a full compat
> with previous functions.
>
> The first solution is your patch + add a shift in rte_set_log_type().
> It would work except if an application uses rte_get_log_type() and masks
> the result with a RTE_LOGTYPE_* (which will not be a bitmask). I think
> it's a rare case.
>
> The second approach would be to define new constants for the new
> functions and keep the old ones for the old functions. This approach
> is probably more confusing. It also requires to check the doc and
> examples again.
>
> Any opinion?
> I would prefer the first solution. If you want I can send a patch
> updated based on yours.
Oh yes, I missed that too. First option looks ok to me, so send a patch if you like.
next prev parent reply other threads:[~2017-04-13 8:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-12 14:14 [PATCH] eal: redefine logtype values Pablo de Lara
2017-04-12 15:15 ` Thomas Monjalon
2017-04-12 15:22 ` De Lara Guarch, Pablo
2017-04-12 15:35 ` [PATCH v2] " Pablo de Lara
2017-04-12 19:23 ` Olivier MATZ
2017-04-13 8:32 ` De Lara Guarch, Pablo [this message]
2017-04-13 9:09 ` De Lara Guarch, Pablo
2017-04-12 21:41 ` Stephen Hemminger
2017-04-13 13:43 ` De Lara Guarch, Pablo
2017-04-13 13:42 ` [PATCH v3] " Pablo de Lara
2017-04-18 9:57 ` Olivier MATZ
2017-04-19 11:12 ` De Lara Guarch, Pablo
2017-04-19 11:22 ` [PATCH] " Pablo de Lara
2017-04-19 11:23 ` De Lara Guarch, Pablo
2017-04-19 11:24 ` [PATCH v4] " Pablo de Lara
2017-04-19 12:15 ` Olivier MATZ
2017-04-19 13:46 ` De Lara Guarch, Pablo
2017-04-19 14:06 ` [PATCH v5] " Pablo de Lara
2017-04-19 14:16 ` Olivier MATZ
2017-04-19 22:49 ` Thomas Monjalon
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=E115CCD9D858EF4F90C690B0DCB4D897478096D4@IRSMSX108.ger.corp.intel.com \
--to=pablo.de.lara.guarch@intel.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
--cc=thomas.monjalon@6wind.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.