Re: [PATCH 02/13] drm/i915: Introduce the i915_user_extension_method

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 13/03/2019 11:46, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-03-13 11:35:55)
> [snip]
>> Shall we only reserve some space with a flags and some rsvd fields just
>> in case it will need to change/grow?
> 
> The only thing that occurs to me is to exchange the next pointer with a
> table of next[] (C++ here we come). But I ask myself, could any
> extension like not be part of the next layer?
> 
> That is if any particular extension needs to chain up to more than one
> iface, it can call each itself:
> 
> struct hypothetical_extension {
> 	struct i915_user_extension base;
> 
> 	u64 iface1_extension;
> 	u64 iface2_extension;
> 	...
> 	u64 ifaceN_extension;
> }
> 
> ? So far I haven't thought of anything I can't weasel my way out by
> punting the problem to the caller :)

Just top make sure we are on the same page, I was thinking of:

struct i915_user_extension {
	__u64 next_extension;
	__u64 name;
	__u32 flags;
	__u32 rsvd[7];
};

So we could add things like:

/* Store each extension return code in rsvd[0]. */
#define I915_USER_EXTENSION_STORE_RESULT (1)

/* Only check whether extensions are known by the driver. */
#define I915_USER_EXTENSION_DRY_RUN. (2)

And things like that. Because we are putting in a generic extension 
mechanism I am worried that if it itself turns out to have some 
limitation we will not have wiggle room to extend it.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx