Re: [RFC v2 0/6] DRM logging tidy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
be killed off as an anachronistic OS compat layer.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux