Hi Lucas,
> > I am reproposing this patch exactly as it was proposed initially
> > where the original interfaces are kept where they have been
> > originally placed. It might generate some duplicated code but,
> > well, it's debugfs and I don't see any issue. In the future we
> > can transform the upper interfaces to act upon all the GTs and
> > provide information from all the GTs. This is, for example, how
> > the sysfs interfaces will act.
>
> NACK. We've made this mistake in the past for other debugfs files.
> We don't want to do it again just to maintain 2 separate places for
> one year and then finally realize we want to merge them.
In my opinion it's all about what mistake you like the most
because until we will have multi-gt support in upstream all the
patches come with the "promise" of a follow-up and maintenance
cost.
> > The reason I removed them in V1 is because igt as only user is
> > not a strong reason to keep duplicated code, but as Chris
> > suggested offline:
> >
> > "It's debugfs, igt is the primary consumer. CI has to be bridged over
> > changes to the interfaces it is using in any case, as you want
> > comparable results before/after the patches land.
>
> That doesn't mean you have to copy and paste it. It may mean you
> do the implementation in one of them and the other calls that implementation.
> See how I did the deduplication in commit d0c560316d6f ("drm/i915:
> deduplicate frequency dump on debugfs")
In this case, from a user perspective, which gt is the interface
affecting? is it affecting all the system? or gt 0, 1...? Does
the user know? The maintenance cost is that later you will need
to use for_each_gt and make all those interfaces multitile, and
this would be your "promise".
How are you going to do it then? Will every interface iterate and
perform its own action? When you read, whad do you read? all the
gt values in 'or'? in 'and'? Is there any common strategy? Or
will we have inconsistent behaviors?
In sysfs (where we are left with the same questions) some times
ago I proposoed a common solution for all the upper level files
in order to provide the user with a consistent interface all
along the GTs.
This is my "promise" and until then it's just a matter of what
promise and what mistake you like the most.
> Alternative would be to prepare igt already and then add a Test-with:
> in this patch
> series.... But I think it makes more sense to support both locations
> for some time and then later
> remove the previous one.
Anyway, I can sure do something similar to how you did it, it
might look prettier but it doesn't exclude a follow-up
improvement.
Thanks for the review,
Andi
