lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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