On Sat, 30 Mar 2024 at 16:46, Stephen Hemminger <step...@networkplumber.org> wrote: > > If DPDK application is being run as a systemd service, then > it can use the journal protocol which allows putting more information > in the log such as priority and other information. > > The use of journal protocol is automatically detected and > handled. Rather than having a dependency on libsystemd, > just use the protocol directly as defined in: > https://systemd.io/JOURNAL_NATIVE_PROTOCOL/ > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > --- > doc/guides/prog_guide/log_lib.rst | 14 ++ > lib/eal/common/eal_common_options.c | 11 ++ > lib/eal/common/eal_options.h | 2 + > lib/log/log.c | 5 + > lib/log/log_internal.h | 3 + > lib/log/log_journal.c | 200 ++++++++++++++++++++++++++++ > lib/log/log_private.h | 2 + > lib/log/log_stubs.c | 11 +- > lib/log/meson.build | 10 +- > lib/log/version.map | 1 + > 10 files changed, 255 insertions(+), 4 deletions(-) > create mode 100644 lib/log/log_journal.c
This is very nice work, I like it a lot! > +/* > + * send structured message using journal protocol > + * See: https://systemd.io/JOURNAL_NATIVE_PROTOCOL/ > + */ > +static int > +journal_send(const char *buf, size_t len) > +{ > + struct iovec iov[4]; > + unsigned int n = 0; > + int priority = rte_log_cur_msg_loglevel() - 1; > + char msg[] = "MESSAGE="; > + char newline = '\n'; > + char pbuf[16]; /* "PRIORITY=N\n" */ > + > + iov[n].iov_base = msg; > + iov[n++].iov_len = strlen(msg); > + > + iov[n].iov_base = (char *)(uintptr_t)buf; > + iov[n++].iov_len = len; > + > + /* if message doesn't end with newline, one will be applied. */ > + if (buf[len - 1] != '\n') { > + iov[n].iov_base = &newline; > + iov[n++].iov_len = 1; > + } > + > + /* priority value between 0 ("emerg") and 7 ("debug") */ > + iov[n].iov_base = pbuf; > + iov[n++].iov_len = snprintf(pbuf, sizeof(pbuf), > + "PRIORITY=%d\n", priority); > + > + return writev(log_journal_fd, iov, n); > +} Doesn't need to be implemented immediately, but the nicest thing about talking directly to the journal is the ability to send lots of arbitrary and useful metadata together with a message, so would be nice if the logging function took an optional string vector that is appended, or some other such mechanism. A very useful example is creating a UUID and then setting MESSAGE_ID=uuid when logging particularly important messages that are useful to filter by this type - for example, when an interface state changes to up/down. That way, one can do 'journalctl MESSAGE_ID=abc..' and get all messages about interface state changes. A project can also ship a catalog file that adds additional context to each ID, that is automatically parsed and displayed to users.
