On 2/7/22 05:02, Jani Nikula wrote:
On Thu, 20 Jan 2022, Casey Bowman <casey.g.bowman@xxxxxxxxx> 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@xxxxxxxxx) 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
