|
XenevaOS
|
#include <xe_drm.h>
Public Attributes | |
| __u64 | next_extension |
: Name of the extension. | |
Note that the name here is just some integer. Also note that the name space for this is not global for the whole driver, but rather its scope/meaning is limited to the specific piece of uAPI which has embedded the struct drm_xe_user_extension. | |
| __u32 | name |
| __u32 | pad |
DOC: Xe IOCTL Extensions
Before detailing the IOCTLs and its structs, it is important to highlight that every IOCTL in Xe is extensible.
Many interfaces need to grow over time. In most cases we can simply extend the struct and have userspace pass in more data. Another option, as demonstrated by Vulkan's approach to providing extensions for forward and backward compatibility, is to use a list of optional structs to provide those extra details.
The key advantage to using an extension chain is that it allows us to redefine the interface more easily than an ever growing struct of increasing complexity, and for large parts of that interface to be entirely optional. The downside is more pointer chasing; chasing across the __user boundary with pointers encapsulated inside u64.
Example chaining:
.. code-block:: C
struct drm_xe_user_extension ext3 { .next_extension = 0, // end .name = ..., }; struct drm_xe_user_extension ext2 { .next_extension = (uintptr_t)&ext3, .name = ..., }; struct drm_xe_user_extension ext1 { .next_extension = (uintptr_t)&ext2, .name = ..., };
Typically the struct drm_xe_user_extension would be embedded in some uAPI struct, and in this case we would feed it the head of the chain(i.e ext1), which would then apply all of the above extensions. struct drm_xe_user_extension - Base class for defining a chain of extensions
| __u32 drm_xe_user_extension::name |
| __u64 drm_xe_user_extension::next_extension |
@next_extension:
Pointer to the next struct drm_xe_user_extension, or zero if the end.
| __u32 drm_xe_user_extension::pad |
@pad: MBZ
All undefined bits must be zero.
1.9.8