[Intel-xe] [PATCH 19/21] drm/xe/uapi: Drop OA_IOCTL_VERSION

[Umesh Nerlige Ramappa]

On Wed, Oct 04, 2023 at 08:28:59PM -0700, Dixit, Ashutosh wrote:
>On Tue, 03 Oct 2023 19:37:58 -0700, Umesh Nerlige Ramappa wrote:
>>
>> On Tue, Sep 19, 2023 at 10:02:53AM -0700, Dixit, Ashutosh wrote:
>> > On Tue, 19 Sep 2023 09:10:47 -0700, Ashutosh Dixit wrote:
>> >>
>> >> OA version was previously used to track which OA properties were introduced
>> >> at which version. However OA version is an outlier in that a similar
>> >> version is not used anywhere else in the kernel.
>> >
>> > This is not strictly true. E.g. AMD's include/uapi/linux/kfd_ioctl.h
>> > contains KFD_IOCTL_MAJOR_VERSION/KFD_IOCTL_MINOR_VERSION.
>> >
>> >> For XE, we will track addition of new properties by means of
>> >> xe_user_extension. Userland can either maintain a mapping of OA properties
>> >> against the kernel version, or rely on return codes (e.g. ENOTSUPP) to
>> >> "discover" OA properties.
>> >
>> > But let's see if we need a version for OA or the kernel version itself is
>> > sufficient.
>> >
>> >>
>> >> Suggested-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
>> >> Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
>>
>> ok, if there is precedence for a version, no harm adding it, but I agree
>> that we should see if there are ways to do this with the generic OA
>> query. For features that are added with extensions, it's taken care of
>> inherently.
>
>Afaiu, in this case userland is still relying on return codes from the
>kernel to discover available features, whereas a version or capability
>flags allow userland to know available features a priori without
>"discovery" by means of return codes.
>
>> Sometimes there are features that are internal to the implementation that
>> the user might want to know. Those may need to be exposed via
>> capabilities/flags in the generic oa/perf query.
>
>I agree that capability flags do appear to be a better option than a
>version. But in i915 we could update the version without modifying the uapi
>header, which we cannot do if we have capability flags (we'd e.g. at least
>have to expose a new capability bit). Is modifying the uapi header a
>concern?
>

IMO, capability is still a uApi, so any such flags should be part of the 
header. 

Thanks,
Umesh

>Both the version and capability flags can be easily included in the oa_info
>struct we are considering now.
>
>Thanks.
>--
>Ashutosh