Received-SPF: pass (google.com: domain of linux-kernel+bounces-84796-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 28 Feb 2024 10:55:42 +0100
From: Petr Mladek <pmladek@suse.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Matthew Wilcox <willy@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/12] drm/i915: Indicate which pipe failed the fastset
 check overall
Message-ID: <Zd8CtrOmb8nfGBdl@alley>
References: <20240215164055.30585-1-ville.syrjala@linux.intel.com>
 <20240215164055.30585-2-ville.syrjala@linux.intel.com>
 <ZdfApN1h97GTfL1t@intel.com>
 <Zdj2ONs8BZ6959Xb@intel.com>
 <87bk83mfwp.fsf@intel.com>
 <1013ff2d-76b2-41f9-a5d4-39a567a3b0cc@rasmusvillemoes.dk>
 <Zd4qrLVWcacza747@intel.com>
 <fa42285b-099e-4d2d-9368-58cea7f67010@rasmusvillemoes.dk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fa42285b-099e-4d2d-9368-58cea7f67010@rasmusvillemoes.dk>

On Wed 2024-02-28 09:32:37, Rasmus Villemoes wrote:
> On 27/02/2024 19.32, Ville Syrj?l? wrote:
> > On Tue, Feb 27, 2024 at 10:38:10AM +0100, Rasmus Villemoes wrote:
> >> On 26/02/2024 15.57, Jani Nikula wrote:
> So if we really want to go down this road, I think it should be
> something like %pX{drm:whatever}, with core printf just looking up the
> token "drm" in a run-time list of registered callbacks (because I don't
> want vsprintf.c filled with random subsystems' formatting code), and
> that single callback would then be handed a pointer to the rest of the
> format string (i.e. the "whatever}..."), the pointer argument from the
> varargs, and the buf,end pair. But then we're back to trusting that
> callback (which might of course multiplex based on the "whatever" part)
> to behave correctly. And then we might as well avoid the string parsing
> and just do the "callback + pointer" in one struct (passed as pointer to
> compound literal), which also avoids the tricky "what to do about module
> unload versus unregistering of callbacks" etc.

Mathew Wilcox had the idea to introduce a structure:

	struct printf_state {
	       char *buf;
	       char *end;
	       void *ptr;
	};

Where *ptr would point to some data which should be printed,
same as wee pass to the %pbla now.

Then allow to implement:

	char *my_func(struct printf_state *ps, void *ptr);

and use it as:

	printk("%pX(%p)\n", my_func, ptr);


One problem here is type checking of the data passed via *ptr
but we already have the same problem now.

Another problem is how to make sure that the function is safe.
A solution might be to implement an API for appending characters,
strings, numbers, ... Similar to seq_buf() API.

AFAIK, the result was to actually use the existing seq_buf API
to format the string. AFAIK, it motivated:

   + commit 96928d9032a7c34f1 ("seq_buf: Add seq_buf_do_printk() helper")

and probably also

   + commit d0ed46b60396cfa7 ("tracing: Move readpos from seq_buf to trace_seq")

and also this one is pretty useful:

   + commit dcc4e5728eeaeda8 ("seq_buf: Introduce DECLARE_SEQ_BUF and
     seq_buf_str()")

And it motivated:

   + commit dcc4e5728eeaeda84878ca0 ("seq_buf: Introduce
     DECLARE_SEQ_BUF and seq_buf_str()")


Best Regards,
Petr