Re: [RFC PATCH 00/20] Initial Xe driver submission

[Boris Brezillon <boris.brezillon@collabora.com>]

+Frank, who's also working on the pvr uAPI.

Hi,

On Thu, 22 Dec 2022 14:21:07 -0800
Matthew Brost <matthew.brost@intel.com> wrote:

> The code has been organized such that we have all patches that touch areas
> outside of drm/xe first for review, and then the actual new driver in a separate
> commit. The code which is outside of drm/xe is included in this RFC while
> drm/xe is not due to the size of the commit. The drm/xe is code is available in
> a public repo listed below.
> 
> Xe driver commit:
> https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7
> 
> Xe kernel repo:
> https://cgit.freedesktop.org/drm/drm-xe/

Sorry to hijack this thread, again, but I'm currently working on the
pancsf uAPI, and I was wondering how DRM maintainers/developers felt
about the new direction taken by the Xe driver on some aspects of their
uAPI (to decide if I should copy these patterns or go the old way):

- plan for ioctl extensions through '__u64 extensions;' fields (the
  vulkan way, basically)
- turning the GETPARAM in DEV_QUERY which can return more than a 64-bit
  integer at a time
- having ioctls taking sub-operations instead of one ioctl per
  operation (I'm referring to VM_BIND here, which handles map, unmap,
  restart, ... through a single entry point)

Regards,

Boris