Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Bowman <casey.g.bowman@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: michael.cheng@intel.com, jani.nikula@intel.com,
	lucas.demarchi@intel.com, daniel.vetter@intel.com
Subject: [Intel-gfx] [RFC PATCH v3 0/1] Splitting up platform-specific calls
Date: Tue, 15 Feb 2022 15:41:45 -0800	[thread overview]
Message-ID: <20220215234146.304035-1-casey.g.bowman@intel.com> (raw)

In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.

I would like to address the following:

1. How do we want to split architecture calls? Different object files
per platform? Separate function calls within the same object file?

2. How do we address dummy functions? If we have a function call that is
used for one or more platforms, but is not used in another, what should
we do for this case?

I've given an example of splitting an architecture call
in my patch with run_as_guest() being split into different
implementations for x86 and arm64 in separate object files, sharing
a single header.

Another suggestion from Michael (michael.cheng@intel.com) involved
using a single object file, a single header, and splitting various
functions calls via ifdefs in the header file.

I would appreciate any input on how we can avoid scaling issues when
including multiple architectures and multiple functions (as the number
of function calls will inevitably increase with more architectures).

v2: Revised to use kernel's platform-splitting scheme.
v3: Revised to use simple if-else structure.

Casey Bowman (1):
  i915/drm: Split out x86/arm64 for run_as_guest

 drivers/gpu/drm/i915/i915_drv.h | 8 ++++++++
 1 file changed, 8 insertions(+)

-- 
2.25.1


             reply	other threads:[~2022-02-15 23:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 23:41 Casey Bowman [this message]
2022-02-15 23:41 ` [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest Casey Bowman
2022-03-21 23:34   ` Casey Bowman
2022-03-22  2:01     ` Lucas De Marchi
2022-03-22 10:21       ` Jani Nikula
2022-03-22 14:27         ` Lucas De Marchi
2022-03-22 14:49           ` Jani Nikula
2022-03-22 15:18             ` Tvrtko Ursulin
2022-03-22 15:23               ` Tvrtko Ursulin
2022-03-22 15:26               ` Jani Nikula
2022-03-22 15:46                 ` Tvrtko Ursulin
2022-03-22 15:52                   ` Jani Nikula
2022-03-22 16:50             ` Lucas De Marchi
2022-02-17  2:12 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Splitting up platform-specific calls (rev3) Patchwork

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=20220215234146.304035-1-casey.g.bowman@intel.com \
    --to=casey.g.bowman@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=michael.cheng@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