From: Sam Ravnborg <sam@ravnborg.org>
To: Jani Nikula <jani.nikula@intel.com>
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: Mon, 23 Dec 2019 13:35:00 +0100 [thread overview]
Message-ID: <20191223123500.GC10745@ravnborg.org> (raw)
In-Reply-To: <87r20vuvow.fsf@intel.com>
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.
On top of this - there is today no gain using drm_device * versus device *.
The output is exactly the same.
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.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-12-23 12:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 9:55 [RFC PATCH 0/9] drm: add more new-style logging functions Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 1/8] drm/print: document " Sam Ravnborg
2019-12-23 11:23 ` Jani Nikula
2019-12-23 12:07 ` Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 2/8] drm/print: move new style " Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 3/8] drm/print: add new logging helper for drm logging Sam Ravnborg
2019-12-23 11:16 ` Jani Nikula
2019-12-23 11:18 ` Joe Perches
2019-12-23 12:10 ` Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 4/8] drm/print: add kernel-doc for drm_debug_enabled Sam Ravnborg
2019-12-23 11:18 ` Jani Nikula
2019-12-21 9:55 ` [PATCH v1 5/8] drm/print: rename drm_dev_dbg Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 6/8] drm/print: add drm_dev_* logging functions Sam Ravnborg
2019-12-21 13:56 ` Joe Perches
2019-12-21 14:48 ` Sam Ravnborg
2019-12-23 11:21 ` Jani Nikula
2019-12-23 11:29 ` Jani Nikula
2019-12-23 12:35 ` Sam Ravnborg [this message]
2019-12-31 14:35 ` Jani Nikula
2019-12-21 9:55 ` [PATCH v1 7/8] drm/print: add drm_pr_ logging Sam Ravnborg
2019-12-21 9:55 ` [PATCH v1 8/8] drm/print: let legacy logging use new style functions Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191223123500.GC10745@ravnborg.org \
--to=sam@ravnborg.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=joe@perches.com \
--cc=sean@poorly.run \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.