[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