On Thu, Jul 23, 2020 at 05:26:44PM +0200, Steven Rostedt wrote:
> On Thu, 23 Jul 2020 12:57:35 +0200
> Vincent Whitchurch wrote:
>
> > Would it be acceptable to just use a fixed size for the event? At least
> > for my own debugging use cases it's preferable to just have to increase
> > the
On Thu, 23 Jul 2020 16:08:44 +0206
John Ogness wrote:
> For me a trace event represents a specific point in the kernel code. But
> this new printk trace event, instead, represents general log
> redirection. I do not oppose it, but it feels like a hack to me. In
> contrast, simply setting a
On Thu, 23 Jul 2020 12:57:35 +0200
Vincent Whitchurch wrote:
> Would it be acceptable to just use a fixed size for the event? At least
> for my own debugging use cases it's preferable to just have to increase
> the trace buffer size in case it's insufficient, rather than to have to
> restort to
On 2020-07-23, John Ogness wrote:
> For me a trace event represents a specific point in the kernel
> code.
Actually, after revisiting Vincent's original patch (adding a "dynamic"
event in the "printk" group and placing the event within the
dynamic_printk printing path), I would fully support the
On 2020-07-22, Steven Rostedt wrote:
>>> +static void dynamic_printk(unsigned int flags, const char *fmt, ...)
>>> +{
>>> + if (flags & _DPRINTK_FLAGS_TRACE) {
>>> + va_list args;
>>> +
>>> + va_start(args, fmt);
>>> + /*
>>> +* All callers include the
On Wed, Jul 22, 2020 at 05:28:23PM +0200, Steven Rostedt wrote:
> For you, I made this quick patch. If this works for you, I can make it
> into a formal patch. It includes a test use case in do_sys_openat2() to
> show the file name and file descriptor. Obviously, that wont be part of
> the final
On Wed, 22 Jul 2020 15:58:22 +0206
John Ogness wrote:
> >> +static void dynamic_printk(unsigned int flags, const char *fmt, ...)
> >> +{
> >> + if (flags & _DPRINTK_FLAGS_TRACE) {
> >> + va_list args;
> >> +
> >> + va_start(args, fmt);
> >> + /*
> >> + * All
On Wed, 22 Jul 2020 16:49:52 +0200
Vincent Whitchurch wrote:
> Do we really need a separate tracing event for this? Why not just:
> >
> > ftrace_vprintk(fmt + strlen(KERN_DEBUG), args);
>
> Thanks, I tried that out now and it seems to work, but it results in the
>
On Wed, Jul 22, 2020 at 03:52:22PM +0200, John Ogness wrote:
> On 2020-07-21, Steven Rostedt wrote:
> >> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> >> index 321437bbf87d..9f6d8867af7c 100644
> >> --- a/lib/dynamic_debug.c
> >> +++ b/lib/dynamic_debug.c
> [..]
> >> +static void
On 2020-07-21, Steven Rostedt wrote:
>> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
>> index 321437bbf87d..9f6d8867af7c 100644
>> --- a/lib/dynamic_debug.c
>> +++ b/lib/dynamic_debug.c
[..]
>> +static void dynamic_printk(unsigned int flags, const char *fmt, ...)
>> +{
>> +if (flags
On (20/07/21 17:30), Steven Rostedt wrote:
> On Tue, 21 Jul 2020 16:11:05 +0200
> Vincent Whitchurch wrote:
>
> > When debugging device drivers, I've found it very useful to be able to
> > redirect existing pr_debug()/dev_dbg() prints to the trace buffer
> > instead of dmesg. Among the many
Added printk maintainers to get their thoughts.
On Tue, 21 Jul 2020 16:11:05 +0200
Vincent Whitchurch wrote:
> When debugging device drivers, I've found it very useful to be able to
> redirect existing pr_debug()/dev_dbg() prints to the trace buffer
> instead of dmesg. Among the many
When debugging device drivers, I've found it very useful to be able to
redirect existing pr_debug()/dev_dbg() prints to the trace buffer
instead of dmesg. Among the many advantages of the trace buffer is that
it can be dynamically resized, allows these prints to combined with
other trace events,
13 matches
Mail list logo
