[PATCH 02/13] drm: drm_printer: Add printer for devcoredump

[Chris Wilson]

Quoting Jordan Crouse (2018-07-12 19:59:19)
> Add a drm printer suitable for use with the read callback for
> devcoredump or other suitable buffer based output format that
> isn't otherwise covered by seq_file.
> 
> Signed-off-by: Jordan Crouse <jcrouse at codeaurora.org>
> ---
>  drivers/gpu/drm/drm_print.c | 74 +++++++++++++++++++++++++++++++++++++
>  include/drm/drm_print.h     | 27 ++++++++++++++
>  2 files changed, 101 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index b25f98f33f6c..03d1f98e5ac7 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -30,6 +30,80 @@
>  #include <drm/drmP.h>
>  #include <drm/drm_print.h>
>  
> +void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
> +{
> +       struct drm_print_iterator *iterator = p->arg;
> +       ssize_t len;
> +
> +       if (!iterator->remain)
> +               return;
> +
> +       /* Figure out how big the string will be */
> +       len = snprintf(NULL, 0, "%pV", vaf);

I was thinking there's some duplication here (kmalloc + snprintf) that
could be reduced to kasprintf here. Is avoiding that allocation
important or frequent enough to merit open coding?

It's pity the kernel's printk doesn't support %n, so that leaves with

buf = kasprintf(GFP_... , "%pV", vaf);
if (!buf)
	return;

len = strlen(buf);

and even the copy + increment looks like it can then be factored to share
more code.
-Chris