[Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls

[Casey Bowman]

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
>> 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 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
> platform.
>
> 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
> other:
>
> #if IS_ENABLED(CONFIG_X86)
> ...
> #elif IS_ENABLED(CONFIG_ARM64)
> ...
> #endif
>
> 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).

>
> BR,
> Jani.
>
>> 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