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
