Message-ID: <20220531220316.i7wl34puxy73zn46@moria.home.lan>
Date:   Tue, 31 May 2022 18:03:16 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org,
        rostedt@...dmis.org, senozhatsky@...omium.org,
        andriy.shevchenko@...ux.intel.com, willy@...radead.org
Subject: Re: [PATCH v2 01/28] lib/printbuf: New data structure for printing
 strings

On Fri, May 27, 2022 at 12:29:20PM +0200, Petr Mladek wrote:
> I would really like to keep the three APIs separated and easy to
> distinguish. They are principally different:
> 
> 1. pr_*() API:
> 
>        + wrapper to printk(). They makes the messages available on
> 	 console and for user-space log daemons while printf()
> 
>       + the various pr_*() variants are used to define kernel
> 	specific features and behavior, for example:
> 	loglevel, ratelimit, only once. deferred console handling.
> 
>        + uses implicit (system) buffer
> 
>        + The message format is defined by the 1st parameter. It
> 	 is the same way as printf() in user-space.
> 
>        + It is inspired by printf() from user-space that prints
> 	 the messages to the standard output.
> 
> 
> 2. *s*printf() APIs:
> 
>        + basically duplicate the same user-space API. It supports
> 	 some extra %p modifiers. There might be few more
> 	 incompatibilities.
> 
>        + use simple "char *" buffer provided as the 1st parameter
> 
>        + the messages format is defined the same way as in
> 	 the user-space counterparts.

I'd like to get sprintf() style functions - anything that outputs to raw char *
pointers - deprecated. That's going to mean a _lot_ of refactoring (so I don't
know that I'll be the one to do it), but it's mostly easy refactoring.

> 3. printbuf API:
> 
>        + append messages into the given printbuf by small pieces
> 
>        + format defined by the suffix, for example, _char(),
> 	 bytes(), units_64(), _tab(), indent()
> 
>        + allows to do special operations on the buffer,
> 	 for example, _reset(), make_room(), atomic_inc()
> 
>        + it will be used as low-level API for vscnprinf()
> 	 implementation, pretty printing API, or
> 	 stand alone uses.
> 
>        + I wonder if there will be variant that will allow
> 	 to pass the format in the printf() way, e.g.
> 	 int pb_printf(printbuf *buf, const char *fmt, ...);

Right now this is called pr_buf(). I suppose pr_printf()/pb_printf() makes sense
:)

> 
>        + is there any user space counter part?
> 
> 
> Now, it is clear that printfbuf API must be distinguished by another
> prefix:
> 
>        + it must be clear that it stores the output into printbuf.
> 	 It is similar to dprintf(), fprintf(), sprintf().
> 
>        + It can't be done by the suffix because it is already used
> 	 to define format of the appended string or extra operation.
> 
>        + It must be clear what is low-level API used to implement
> 	 vsprintf() and high-level API that uses vsprintf().
> 	 I mean pb_char() vs. pb_printf().

So there's more in the pr_* namespace than I realized - I guess you've convinced
me on not reusing that. Which is a shame, because it rolls off the tongue so
much easier than pb_* and I think otherwise makes more sense here - pr_foo for
"print foo".

However, I'm not going to put special operations on printbufs under the pb_
prefix: I want that naming (whether pb_* or pr_*) to _just_ be for "print foo";
this "print this" prefix should be the common prefix for _any_ pretty printer,
unless it has another subsystem prefix - that means there's going to be a lot of
functions with these prefix. So I'm going to keep "printbuf special operations"
on the printbuf_ prefix.

Also, how about prt_* instead of pb_*? I want something that sounds more like
print, and prt_ isn't taken.

Powered by blists - more mailing lists