On 24/01/2018 16:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-01-24 16:18:15)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
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
What is the standard logging string? the dev_ one?
be killed off as an anachronistic OS compat layer.
You mean only dev variants should be kept?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
