[Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
casey.g.bowman at intel.com
Wed Feb 9 05:07:21 UTC 2022
On 2/7/22 05:02, Jani Nikula wrote:
> On Thu, 20 Jan 2022, Casey Bowman <casey.g.bowman at intel.com> wrote:
>> In this RFC I would like to ask the community their thoughts
>> on how we can best handle splitting architecture-specific
>> 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 at 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).
> Personally I think the functionality is best kept organized by, well,
> functionality, not by platform. Otherwise the platform files will
> contain all sorts of code with the only common denominator being the
> You're also likely to have static platform specific functions, which
> would needlessly have to be made non-static if the split was by files.
> I'd just put the implementations for different platforms next to each
> #if IS_ENABLED(CONFIG_X86)
> #elif IS_ENABLED(CONFIG_ARM64)
> Usually the declarations would be identical and there'd only be one,
> without #ifs in the header.
Thanks for the feedback, Jani.
I think this is the proper takeaway for future functions that do have
separate implementations for differing architectures.
As for null behavior, as in the example I gave, I think Tvrtko is right
about run_as_guest being a tricky example. I think I need to
re-evaluate that function and think of another solution altogether
for that instance.
I think this will also be the precedent for null cases, where we will
need to rethink implementations for cases that don't really have
some arch-specific implementation other than returning null
(though some exceptions may exist).
>> Casey Bowman (1):
>> i915/drm: Split out x86 and arm64 functionality
>> drivers/gpu/drm/i915/Makefile | 4 +++
>> drivers/gpu/drm/i915/i915_drv.h | 6 +---
>> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
>> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
>> 5 files changed, 87 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
More information about the Intel-gfx