[Intel-gfx] [RFC v2 0/6] DRM logging tidy
Chris Wilson
chris at chris-wilson.co.uk
Wed Jan 24 16:23:52 UTC 2018
Quoting Tvrtko Ursulin (2018-01-24 16:18:15)
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>
> This series tries to solve a few issues in the current DRM logging code to
> primarily make it clearer which messages belong to which driver.
>
> Main problem is that currently some logging functions allow individual drivers
> to override the log prefix (since they are defined as macros, or static
> inlines), while other hardcode the "drm" prefix into them due being situated in
> the DRM core modules.
>
> Another thing is that I noticed the DRM_NAME macro which is used for this is
> defined in the uAPI header and had a comment which looked outdated.
>
> Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined
> internally in the kernel headers and not exported in the uAPI.
>
> I also refactored some logging functions to take this string as a parameter
> instead of hardcoding it.
>
> Individual drivers can then override this define to make DRM logging functions
> prefix their message with the respective driver prefix.
>
> End result in the case of the i915 driver looks like this:
>
> Old log:
>
> [drm] Found 128MB of eDRAM
> [drm:skl_enable_dc6 [i915]] Enabling DC6
>
> New log:
>
> [i915] Found 128MB of eDRAM
> [i915:skl_enable_dc6 [i915]] Enabling DC6
And still not conforming to the standard logging string. DRM_LOG should
be killed off as an anachronistic OS compat layer.
-Chris
More information about the Intel-gfx
mailing list