DPDK patches and discussions
 help / color / mirror / Atom feed
From: Feng Li <lifeng1519@gmail.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: Li Feng <fengli@smartx.com>,
	David Marchand <david.marchand@redhat.com>,
	 Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
	Dmitry Malloy <dmitrym@microsoft.com>,
	 Pallavi Kadam <pallavi.kadam@intel.com>,
	Ray Kinsella <mdr@ashroe.eu>,
	 Neil Horman <nhorman@tuxdriver.com>, dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v4] log: support custom log function
Date: Tue, 23 Feb 2021 19:22:54 +0800	[thread overview]
Message-ID: <CAEK8JBB3Ucdzw15QnrTs2P6z50myXjihCfFao1LUQ=x7ttGY6g@mail.gmail.com> (raw)
In-Reply-To: <20210219111120.4e77de89@sovereign>

Hi Dmitry,
Thanks for your comments. I will submit the next patch to address your concern.

On Fri, Feb 19, 2021 at 4:11 PM Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> wrote:
>
> On Thu, 18 Feb 2021 14:12:53 +0800, Li Feng wrote:
> > By default, the dpdk log is out to stdout/stderr and syslog.
> > The rte_openlog_stream could set an external FILE* stream, but it
> > asks the consumer to give it a FILE* pointer.
> > For C++ or other languages, it's hard to get a libc FILE*.
> >
> > Support to set a hook is another choice for this scenario.
> >
> > Signed-off-by: Li Feng <fengli@smartx.com>
> > ---
> > v4: Fix the code style.
> > v3: Rename the func, change the comments, add funcs in version.map.
> > v2: Simplify the code.
>
> While I support the feature in general, its current design is imperfect both
> at interface level (documentation, corner cases) and at interaction with the
> rest of EAL logging subsystem (hijacking Linux EAL internals). IMO, proper
> implementation would rework rte_vlog() to print to buffer, then pass it to
> current logging function. But rte_openlog_stream() has to be supported still.
> What do others think?
OK, I have reworked on rte_vlog, it looks more reasonable.
>
> > +/**
> > + * Define a logging write function.
> > + */
> > +typedef ssize_t rte_log_write_function(void *cookie, const char *buf,
> > +     size_t size);
>
> You're supposed to document callback parameters and behavior here.
> What about its thread-safety?
> It's not obvious what "cookie" means (suggesting "context").
Acked.
>
> > +
> > +/**
> > + * Change the default stream's write action that will be used by the logging
> > + * system.
> > + *
> > + * This should be done before the 'rte_eal_init' call. And the
> > + * 'rte_openlog_stream' call will override this action.
> > + *
> > + * @param logf
> > + *   Pointer to the log write function.
> > + */
> > +__rte_experimental
> > +void
> > +rte_log_sink_set(rte_log_write_function *logf);
>
> Since this API is currently Linux-only, it must report lack of support for
> FreeBSD and Windows, presumably via return value.
Acked.

>
> > +
> > +/**
> > + * Retrieve the log function used by the logging system (see rte_log_sink_set()
> > + * to change it).
> > + *
> > + * @return
> > + *   Pointer to the log function.
> > + */
> > +__rte_experimental
> > +rte_log_write_function*
> > +rte_log_sink_get(void);
>
> Doesn't checkpatch complain about "ret_type*" vs "ret_type *"?
Actually, checkpatch treats it ok.

>
> [...]
> > +/**
> > + * Change the default stream's write action that will be used by the logging
> > + * system.
> > + *
> > + * This should be done before the 'rte_eal_init' call. And the
> > + * 'rte_openlog_stream' call will override this action.
> > + */
>
> It's not very helpful to repeat public documnetation.
> Here is a good place to explain implementation, if required.
Acked.

>
> > +void
> > +rte_log_sink_set(rte_log_write_function *logf)
> > +{
> > +     console_log_func.write = logf;
> > +}
>
> 1. What if NULL is passed? An app will likely crash far from the culprit.
> 2. This breaks EAL writing to syslog. It's probably intended, but please at
> least document such behavior.

OK, I think that if the logf is NULL, then keep the original function.

>
> [...]
> > +/*
> > + * Retrieve the default log write function.
> > + */
> > +rte_log_write_function*
> > +rte_log_sink_get(void)
> > +{
> > +     return NULL;
> > +}
>
> I'd say it's an API inconsistency that you can write logs but sink is not
> callable.
I have rewritten this patch, it will be safe.

      reply	other threads:[~2021-02-24  2:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 11:24 [dpdk-dev] [PATCH] " Li Feng
2021-02-05 11:31 ` Feng Li
2021-02-05 11:55 ` David Marchand
2021-02-05 12:22   ` Feng Li
2021-02-05 14:08     ` Dmitry Kozlyuk
2021-02-05 16:39     ` Stephen Hemminger
2021-02-05 16:10   ` Stephen Hemminger
2021-02-05 16:54     ` Feng Li
2021-02-05 17:06       ` Feng Li
2021-02-05 17:42 ` [dpdk-dev] [PATCH v2] " Li Feng
2021-02-05 17:47   ` Feng Li
2021-02-05 19:32   ` Dmitry Kozlyuk
2021-02-08  6:58     ` Feng Li
2021-02-08 22:40       ` Dmitry Kozlyuk
2021-02-10  3:59         ` Feng Li
2021-02-10  5:20 ` [dpdk-dev] [PATCH v3] " Li Feng
2021-02-18  2:55   ` Feng Li
2023-06-15 16:12   ` Stephen Hemminger
2021-02-18  6:12 ` [dpdk-dev] [PATCH v4] " Li Feng
2021-02-19  8:11   ` Dmitry Kozlyuk
2021-02-23 11:22     ` Feng Li [this message]

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='CAEK8JBB3Ucdzw15QnrTs2P6z50myXjihCfFao1LUQ=x7ttGY6g@mail.gmail.com' \
    --to=lifeng1519@gmail.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=dmitrym@microsoft.com \
    --cc=fengli@smartx.com \
    --cc=mdr@ashroe.eu \
    --cc=navasile@linux.microsoft.com \
    --cc=nhorman@tuxdriver.com \
    --cc=pallavi.kadam@intel.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 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).