On Mon, Feb 26, 2024 at 05:35:51PM +0200, Jani Nikula wrote: > On Mon, 26 Feb 2024, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Mon, Feb 26, 2024 at 04:57:58PM +0200, Jani Nikula wrote: > >> On Fri, 23 Feb 2024, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > On Thu, Feb 22, 2024 at 04:46:12PM -0500, Rodrigo Vivi wrote: ... > >> > I think the proper solution would be to have actually > >> > sensible conversion specifiers in the format string. > >> > So instead of %<set of random characters> we'd have something > >> > more like %{drm_crtc} (or whatever color you want to throw > >> > on that particular bikeshed). > >> > >> Personally I suck at remembering even the standard printf conversion > >> specifiers, let alone all the kernel extensions. I basically have to > >> look them up every time. I'd really love some %{name} format for named > >> pointer things. And indeed preferrably without the %p. Just %{name}. > > > > It will become something like %{name[:subextensions]}, where subextensions > > is what we now have with different letters/numbers after %pX (X is a letter > > which you proposed to have written as name AFAIU). > > Thanks, I appreciate it, a lot! Oh, I meant "can" rather than "will". > But could you perhaps try to go with just clean %{name} only instead of > adding [:subextensions] right away, please? > > I presume the suggestion comes from an implementation detail, and I > guess it would be handy to reuse the current implementation for > subextension. > > For example, %pb -> %{bitmap} and %pbl -> %{bitmap:l}. But really I > think the better option would be for the latter to become, say, > %{bitmap-list}. The goal here is to make them easy to remember and > understand, without resorting to looking up the documentation! Okay, so it seems you have something in mind, perhaps you can submit a draft of the list of those "names"? > >> And then we could discuss adding support for drm specific things. I > >> guess one downside is that the functions to do this would have to be in > >> vsprintf.c instead of drm. Unless we add some code in drm for this > >> that's always built-in. -- With Best Regards, Andy Shevchenko