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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux