[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190903140420.kmb42cwr3scrfd3e@pathway.suse.cz>
Date: Tue, 3 Sep 2019 16:04:20 +0200
From: Petr Mladek <pmladek@...e.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung@...nel.org>, rafael@...nel.org,
Rob Herring <robh@...nel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jiri Olsa <jolsa@...hat.com>, devicetree@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-devel@...r.kernel.org,
Tzvetomir Stoyanov <tstoyanov@...are.com>
Subject: Re: [PATCH v4 07/11] lib/vsprintf: Remove support for %pF and %pf in
favour of %pS and %ps
On Mon 2019-09-02 19:01:39, Andy Shevchenko wrote:
> On Mon, Sep 02, 2019 at 04:39:35PM +0200, Petr Mladek wrote:
> > On Mon 2019-09-02 11:32:36, Sakari Ailus wrote:
> > > %pS and %ps are now the preferred conversion specifiers to print function
> > > names. The functionality is equivalent; remove the old, deprecated %pF
> > > and %pf support.
> >
> > Hmm, I see the following in master:
> >
> > $> git grep %pF
> > tools/lib/traceevent/Documentation/libtraceevent-func_apis.txt:or events have "%pF" or "%pS" parameter in its format string. It is common to
> >
> > $> git grep %pf
> > tools/lib/traceevent/event-parse.c: if (asprintf(&format, "%%pf: (NO FORMAT FOUND at %llx)\n", addr) < 0)
> > tools/lib/traceevent/event-parse.c: if (asprintf(&format, "%s: %s", "%pf", printk->printk) < 0)
> >
> > I wonder how this is related to printk(). In each case, it seems
>
> It's going thru binary printf() I suppose. The fist stage just saves the format
> string and argument addresses or so and prints in later on when user is looking
> for human-readable output.
It seems that vbin_printf() still thinks that %pf and %pF
handle function pointers. If I get it correctly, it just
stores the binary data and the formating is done when
tracing log is read. The idea is the function pointers
will stay the same.
We need to fix/obsolete this path as well.
Best Regards,
Petr
Powered by blists - more mailing lists