[Intel-xe] [PATCH] drm/xe/uapi: Remove DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTY

[Lucas De Marchi]

On Wed, Dec 06, 2023 at 01:11:41PM -0500, Rodrigo Vivi wrote:
>On Wed, Dec 06, 2023 at 05:52:52PM +0000, Souza, Jose wrote:
>> On Wed, 2023-12-06 at 11:48 -0600, Lucas De Marchi wrote:
>> > On Wed, Dec 06, 2023 at 12:42:27PM -0500, Rodrigo Vivi wrote:
>> > > On Wed, Dec 06, 2023 at 10:33:35AM -0600, Lucas De Marchi wrote:
>> > > > On Wed, Dec 06, 2023 at 11:26:18AM -0500, Rodrigo Vivi wrote:
>> > > > > On Wed, Dec 06, 2023 at 10:16:22AM -0600, Lucas De Marchi wrote:
>> > > > > > On Wed, Dec 06, 2023 at 04:06:17PM +0000, Francois Dugast wrote:
>> > > > > > > The exec_queue_set_property feature was removed in a previous
>> > > > > > > commit ("drm/xe/uapi: Kill exec_queue_set_property") and is no
>> > > > > > > longer usable, struct drm_xe_exec_queue_set_property does not
>> > > > > > > exist anymore, so let's remove this.
>> > > > >
>> > > > > my bad, sorry
>> > > > >
>> > > > > > >
>> > > > > > > Signed-off-by: Francois Dugast <francois.dugast at intel.com>
>> > > > > >
>> > > > > > should probably be a fixup to that patch? Anyway,
>> > > > >
>> > > > > no because it is in the uapi header that gets "copied" by the UMDs
>> > > > > and IGT already merged and Mesa likely... and we cannot do fixup
>> > > > > on their sides.
>> > > >
>> > > > wat?
>> > > >
>> > > > any UMDs would just copy the header and point to the commit it came
>> > > > from. It doesn't matter if we used a fixup or not.
>> > >
>> > > But history wouldn't align. If they have already merged the commit with
>> > > the sync pointing to a kernel commit that we do a later fixup, there
>> > > would be a mismatch. Anyone looking the history in a later time would
>> > > think that the UMD code was wrong.
>> > >
>> > > And instead of blaming me for having missed this line in the first
>> > > commit they would unfairly blame whoever authored the UMD patch
>> > >
>> > > right Jose?
>> > >
>> > > But I would be okay with a fixup if that is okay for Jose.
>> >
>> >
>> > when a fixup is amended, it's not like the commit remains the same. You
>> > will have a different hash for the new commit. Just point to the new
>> > commit which has the same commit message as the previous one.
>> >
>> > And we are still on top of drm-tip. All these commits will still be
>> > rebased and have their hashes changed anyway.
>
>for this reason, any patch like this I do in IGT I use the commit subject
>but without any hash.

I think that's a mistake since it doesn't point to the exact commit
that was used while testing that. Same reason why I insist that on any
rebase/force-push we save the previous state by pushing a tag. I don't
want to invalidate tests done in other projects.

The hash identifies the exact commit. Having 2 commits with the same
**title** doesn't seem odd to me and is perfectly fine even if we are
not talking about force pushes.

But I already gave my r-b. I don't care much about this specific patch
being a fixup or not, I just don't agree with or like the motivation ;).

Lucas De Marchi