[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150116083049.706f8f16@grimm.local.home>
Date: Fri, 16 Jan 2015 08:30:49 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Javi Merino <javi.merino@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dave P Martin <Dave.Martin@....com>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [RESEND PATCH v2 1/2] tracing: Add array printing helpers
On Fri, 16 Jan 2015 10:14:14 +0000
Javi Merino <javi.merino@....com> wrote:
> > BUG() is a bit extreme don't you think? I'm not sure it even
> > deserves a WARN_ON().
>
> Ok, I used BUG() because that's what you suggested:
>
> http://article.gmane.org/gmane.linux.kernel/1846749
>
Whoever suggested that was an idiot ;-)
I know why I suggested that but looking at it again with a clearer head
I think it's better not to bug, or even warn. It's on the output side,
for some reason I was thinking it was on the input (saving to buffer)
side.
> The only way I could think of turning it into a BUILD_BUG was by
> moving it to the __print_array macro, but I think it's ugly.
BUILD_BUG is probably better even if it is ugly. But for now, as this
is only to output the data not to save it, printing is better.
>
> > I would suggest doing:
> >
> > trace_seq_printf(p, "BAD SIZE:%d 0x%x",
> > el_size, *(u8 *)ptr);
> > el_size = 8;
> >
> > No need to go crashing the kernel or even messing with dmesg over
> > somebody's tracepoint mistake.
>
> Ok, I'll change it to that.
>
> > The rest looks fine.
> >
> > > + }
> > > + prefix = ",";
> > > + ptr += el_size / 8;
> > > + }
> > > +
> > > + trace_seq_putc(p, '}');
> > > + trace_seq_putc(p, 0);
> >
> > I need to add a trace_seq_terminate() for this.
>
> That would make it more readable. Cheers,
It's on my todo list :-)
Thanks!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists