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 trace
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 dynami
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 K
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 pa
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
> trace_print
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 dynami
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 adva
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 advanta
12 matches
Mail list logo
