All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.