> From: David Marchand [mailto:david.march...@redhat.com] > Sent: Friday, 17 November 2023 15.10 > > On Fri, Nov 17, 2023 at 2:47 PM Morten Brørup > <m...@smartsharesystems.com> wrote: > > > > > From: David Marchand [mailto:david.march...@redhat.com] > > > Sent: Friday, 17 November 2023 14.18 > > > > > > Getting readable and consistent logs is important when running a > DPDK > > > application, especially when troubleshooting. > > > A common issue with logs is when a DPDK change do not add (or on > the > > > contrary add too many \n) in the format string. > > > > > > This issue would only get noticed when actually hitting this log > (which > > > may be something difficult to do). > > > > > > This series proposes to introduce a new RTE_LOG helper that is > > > responsible for logging a one line message and spews a build error > > > (with gcc) if any \n is part of the format string. > > > > > > > The new helper's name is RTE_LOG_LINE, not RTE_LOG. > > Sorry, wrong completion. > > > > > As far as I can see, RTE_LOG continues working as before - allowing > one line of log message to span multiple lines of RTE_LOG() calls with > \n in the last of them. Which is good. > > Indeed, we can't break / change RTE_LOG api. > This API is too old, that would be a nightmare. > > > > > Anyway, I like the concept. And it solves a real problem. > > > > If you want other names, e.g. RTE_LOG for a complete line (appending > \n in the macro itself), and RTE_LOG_PART (or similar) for an > incomplete line, I wouldn't object. But that would probably break the > API. > > No API breaking allowed :-).
OK, then: Series-acked-by: Morten Brørup <m...@smartsharesystems.com>
