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@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