Hi Jani.
> >> I mean is it useful to have this extra printing subsystem in DRM while
> >> the standard Linux one actually does a better job?
> > The added functionality of drm_xxx_err would be to keep the current
> > drm.debug=0x1f filtering on the command-line.
> > I do not think we can do this with the standard logging.
>
> Correct. I'd love the benefits of dynamic debug, but there's no support
> for the kind of message categories that we do with drm.debug.
>
> I've contemplated switching i915 over to using the variants where you
> pass the device, but I really really don't like the idea of:
>
> - DRM_DEBUG_KMS("hello\n");
> + DRM_DEV_DEBUG_KMS(i915->drm.dev, "hello\n");
>
> Where i915 is our private wrapper for drm_device. I think it's just too
> much ugly uppercase boilerplate, and a large portion of the debugs would
> have to span at least an extra line after that.
>
> I'd also very much prefer passing just struct *drm_device instead of
> struct *device. In that, I think the needs of the few have prevailed
> over the needs of the many. I'd definitely prefer drm_err(const struct
> drm_device *drm, ...) and friends over the current ones.
This is from my notes:
"
drm_err(const struct drm_device *drm, ...)
drm_info(const struct drm_device *drm, ...)
drm_kms_err(const struct drm_device *drm, ...)
drm_kms_info(const struct drm_device *drm, ...))
etc.
Then we could fish out relevant info from the drm device and present
this nicely.
For the cases where no drm_device is available the fallback is:
drm_dev_err(const struct drm_device *drm, ...)
drm_dev_info(const struct drm_device *drm, ...))
We could modify the existing UPPERCASE macros to be placeholders for
the more reader friendly lower cases variants.
"
So we seems to be aligned here.
In other words - if you throw time after this then try to add
the new logging variants to drm_print.h for the benefit of all.
The we can maybe later do some mass conversion if we want to get rid
of some of the older logging systems.
I have not yet found time/energy to throw after this myself.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
