From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Li Feng <fengli@smartx.com>
Cc: 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@dpdk.org, lifeng1519@gmail.com
Subject: Re: [dpdk-dev] [PATCH v4] log: support custom log function
Date: Fri, 19 Feb 2021 11:11:20 +0300 [thread overview]
Message-ID: <20210219111120.4e77de89@sovereign> (raw)
In-Reply-To: <20210218061253.2812991-1-fengli@smartx.com>
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?
> +/**
> + * 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").
> +
> +/**
> + * 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.
> +
> +/**
> + * 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 *"?
[...]
> +/**
> + * 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.
> +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.
[...]
> +/*
> + * 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.
next prev parent reply other threads:[~2021-02-19 8:11 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 [this message]
2021-02-23 11:22 ` Feng Li
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=20210219111120.4e77de89@sovereign \
--to=dmitry.kozliuk@gmail.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitrym@microsoft.com \
--cc=fengli@smartx.com \
--cc=lifeng1519@gmail.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).