Re: [PATCH 3/3] drm/panic: Add a kconfig option to dump kunits results to png

[Jocelyn Falempe <jfalempe@redhat.com>]

On 02/09/2025 18:58, Maxime Ripard wrote:
> On Mon, Sep 01, 2025 at 03:04:26PM +0200, Jocelyn Falempe wrote:
>> On 27/08/2025 12:45, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 21.08.25 um 11:49 schrieb Jocelyn Falempe:
>>>> This is a bit hacky, but very handy if you want to customize the
>>>> panic screen.
>>>> It allows to dump the generated images to the logs, and then a python
>>>> script can convert it to .png files. It makes it easy to check how
>>>> the panic screen will look on different resolutions, without having
>>>> to crash a VM.
>>>> To not pollute the logs, it uses a monochrome framebuffer, compress
>>>> it with zlib, and base64 encode it.
>>>
>>> May I suggest to export the raw image via debugfs? Debugfs can also
>>> export additional information in additional files, such as width/height/
>>> stride/format. This could provide the real/last image on the fly, simply
>>> by reading the files. No workarounds or encodings needed.
>>
>> I'm looking into that. The difficulty is to get the debugfs content outside
>> of the test kernel. As I'm using a uml kernel for testing, I will need a
>> special initrd, and a way to share files with the host.
> 
> Yeah, I agree that it's not very practical. If only because the test
> context doesn't stick around once it's been executed, so you would
> effectively leak an arbritrarily long buffer with no hope of getting
> back its memory.

I've made a prototype with debugfs, a small ramdisk with busybox, and 
using hostfs to mount the host filesystem in the uml kernel, and it 
allows to dump the raw panic buffer easily.
Even if it's a bit more complex to setup, I think this use case is not 
really a kunit test, so it's probably better that way.

Let me a few days to clean that up, and I will send a v2 of the kunit 
tests, and a new series to add a debugfs interface.

Thanks for your reviews,

-- 

Jocelyn

> 
> Maxime