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.
prev parent 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).