From: Jani Nikula <jani.nikula@intel.com>
To: Casey Bowman <casey.g.bowman@intel.com>, intel-gfx@lists.freedesktop.org
Cc: michael.cheng@intel.com, lucas.demarchi@intel.com,
daniel.vetter@intel.com
Subject: Re: [Intel-gfx] [RFC PATCH v2 0/1] Splitting up platform-specific calls
Date: Fri, 11 Feb 2022 13:55:02 +0200 [thread overview]
Message-ID: <87sfsp7h49.fsf@intel.com> (raw)
In-Reply-To: <20220211021510.202602-1-casey.g.bowman@intel.com>
On Thu, 10 Feb 2022, Casey Bowman <casey.g.bowman@intel.com> wrote:
> 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.
I think this is overengineering.
Just add different implementations of the functions per architecture
next to where they are now, like I suggested before.
If we need to split them better later, it'll be a trivial undertaking,
and we'll be in a better position to do it because we'll know how many
functions there'll be and where they are and what they do.
Adding a bunch of overhead from the start seems like the wrong thing to
do.
BR,
Jani.
>
> Casey Bowman (1):
> i915/drm: Split out x86 and arm64 functionality
>
> drivers/gpu/drm/i915/Makefile | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 7 ++-----
> drivers/gpu/drm/i915/platforms/Makefile | 8 ++++++++
> .../arm64/include/platform/i915_hypervisor.h | 11 +++++++++++
> .../platforms/x86/include/platform/i915_hypervisor.h | 9 +++++++++
> 5 files changed, 33 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/platforms/Makefile
> create mode 100644 drivers/gpu/drm/i915/platforms/arm64/include/platform/i915_hypervisor.h
> create mode 100644 drivers/gpu/drm/i915/platforms/x86/include/platform/i915_hypervisor.h
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-02-11 11:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 2:15 [Intel-gfx] [RFC PATCH v2 0/1] Splitting up platform-specific calls Casey Bowman
2022-02-11 2:15 ` [Intel-gfx] [RFC PATCH v2 1/1] i915/drm: Split out x86 and arm64 functionality Casey Bowman
2022-02-11 2:20 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Splitting up platform-specific calls (rev2) Patchwork
2022-02-11 11:55 ` Jani Nikula [this message]
2022-02-11 13:51 ` [Intel-gfx] [RFC PATCH v2 0/1] Splitting up platform-specific calls Tvrtko Ursulin
2022-02-15 6:05 ` Casey Bowman
2022-02-15 6:58 ` Lucas De Marchi
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=87sfsp7h49.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=casey.g.bowman@intel.com \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--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 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.