Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>, intel-xe@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 2/2] drm/xe: Make a standalone snapshot to that survives unbind
Date: Wed, 31 Jan 2024 10:58:46 +0200	[thread overview]
Message-ID: <87jznpj2ux.fsf@intel.com> (raw)
In-Reply-To: <20240130223709.50881-2-rodrigo.vivi@intel.com>

On Tue, 30 Jan 2024, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> Instead of having the coredump embedded to the xe device,
> let's dynamically allocate that and remove only when
> requested by devcoredump.

[snip]

> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index 50dac1a5b053..4372f5cc98b6 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -214,7 +214,7 @@ struct xe_device {
>  	struct drm_device drm;
>  
>  	/** @devcoredump: device coredump */
> -	struct xe_devcoredump devcoredump;
> +	struct xe_devcoredump *devcoredump;

Yes! I *much* prefer having pointer members in struct xe_device over
embedding structs, for anything where pointer chasing is not a
performance issue. Which is most things, really. Ditto in struct
drm_i915_private, but converting now is a lot of churn.

Anyway, with dynamic allocation you also don't need the type definition
here. You can just forward declare, and drop the include. This file here
is included by absolutely everywhere, and by proxy, so is
xe_devcoredump_types.h. Modify xe_devcoredump_types.h, and you need to
rebuild the entire driver, including all of display. It adds up.

For added bonus, move the struct definitions inside xe_devcoredump.c,
and make struct xe_devcoredump an opaque pointer. This is one of the few
things C has to enforce use of interfaces to access data. There's no
reason for anyone outside of xe_devcoredump.c to directly access
xe->devcoredump. And making the pointer opaque guarantees nobody
bypasses the interfaces in a whim. Those things happen, "I just quickly
...", and you end up in a mess.


BR,
Jani.


-- 
Jani Nikula, Intel

  reply	other threads:[~2024-01-31  8:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 22:37 [PATCH 1/2] drm/xe: Convert xe_device_snapshot to a standalone snapshot Rodrigo Vivi
2024-01-30 22:37 ` [PATCH 2/2] drm/xe: Make a standalone snapshot to that survives unbind Rodrigo Vivi
2024-01-31  8:58   ` Jani Nikula [this message]
2024-01-31  5:02 ` ✗ CI.Patch_applied: failure for series starting with [1/2] drm/xe: Convert xe_device_snapshot to a standalone snapshot Patchwork
2024-01-31 13:44 ` [PATCH 1/2] " Souza, Jose

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=87jznpj2ux.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox