|
XenevaOS
|
#include <i915_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 i915_user_extension. | |
| __u32 | name |
| __u32 | flags |
| __u32 | rsvd [4] |
struct i915_user_extension - Base class for defining a chain of extensions
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 i915_user_extension ext3 { .next_extension = 0, // end .name = ..., }; struct i915_user_extension ext2 { .next_extension = (uintptr_t)&ext3, .name = ..., }; struct i915_user_extension ext1 { .next_extension = (uintptr_t)&ext2, .name = ..., };
Typically the struct i915_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.
| __u32 i915_user_extension::flags |
@flags: MBZ
All undefined bits must be zero.
| __u32 i915_user_extension::name |
| __u64 i915_user_extension::next_extension |
@next_extension:
Pointer to the next struct i915_user_extension, or zero if the end.
| __u32 i915_user_extension::rsvd[4] |
@rsvd: MBZ
Reserved for future use; must be zero.
1.9.8