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@xxxxxxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
