[Intel-gfx] [RFC v2 0/6] DRM logging tidy
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Jan 24 16:48:03 UTC 2018
On 24/01/2018 16:23, Chris Wilson wrote:
> 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
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
More information about the Intel-gfx
mailing list