Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions

From: Jani Nikula <jani.nikula@intel.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Joe Perches <joe@perches.com>, Sean Paul <sean@poorly.run>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions
Date: Tue, 31 Dec 2019 16:35:55 +0200	[thread overview]
Message-ID: <87a778lfzo.fsf@intel.com> (raw)
In-Reply-To: <20191223123500.GC10745@ravnborg.org>

On Mon, 23 Dec 2019, Sam Ravnborg <sam@ravnborg.org> wrote:
> Hi Jani.
>
> On Mon, Dec 23, 2019 at 01:29:19PM +0200, Jani Nikula wrote:
>> On Sat, 21 Dec 2019, Sam Ravnborg <sam@ravnborg.org> wrote:
>> > There are a lot of cases where we have a device * but no drm_device *.
>> > Add drm_dev_* variants of the logging functions to cover these cases.
>> 
>> So I know there are some valid cases where we only have struct device *,
>> and instead of passing struct drm_device * will need the distinction
>> between multiple struct device *.
>> 
>> Not all current uses of DRM_DEV_* meet that criteria, however. I think
>> I'd like to have those converted over to the drm_device based logging
>> first, and then see what's left. Because I fear adding these will just
>> lead to mass conversion from DRM_DEV_* to drm_dev_*, and the ball gets
>> dropped there.
>
> Hmm...
> $ git grep -E '(DRM_DEV_ERROR|DRM_DEV_INFO|DRM_DEV_WARN|DRM_DEV_DEBUG)'
> 953
> There are 4 hits in drm/* - the rest is in drivers (no suprise).
>
>
> $ git grep -E '(DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)' | wc -l
> 8380
> There are 626 hits in drm/* - the rest in drivers.
>
>
> So moving over all DRM_DEV looks doable with a lot of effort. It touches
> all drivers.
> But the non-DEV variants - thats just too much.
> This is a lot of effort required before we can offer new drivers
> a simple a logical logging solution.

I guess that's part of the point. Do we even want to offer new non-dev
based alternatives for (DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)? We'll
end up carrying the alternatives for years. And face tons of churn for
no real benefit. Why not just stick to the old ones when you're not
using a drm device based alternative?

Switching from non-dev based logging to drm device based logging, OTOH,
is worth the churn.

> On top of this - there is today no gain using drm_device * versus device *.
> The output is exactly the same.

For me and i915 the gain is in not having to do the dereference
everywhere. Having drm device available is the more common case.

If you go through the current DRM_DEV_* uses, a significant portion of
them use drm->dev or have drm device readily available. Again, I'd
prefer converting them over to drm device instead of just changing the
call to another struct device based version. And then see how big the
demand really is for struct device based logging before adding all
possible variations of it. Could they do with less?

Using drm device gives us the benefit that we can also add drm device
based debug control if we want, for example to enable debug only for a
certain device in a multi-GPU system. That option is not easily
available with struct device based logging.

> We should discuss what is required before we can offer the full solution
> for new drivers. And how much the existing usage should hold this back.

I guess I'm more concerned about existing drivers and the conversion
than new drivers...

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel