[Intel-gfx] [RFC] drm/i915: Rename global i915 to i915_params

Jani Nikula jani.nikula at linux.intel.com
Wed Sep 13 08:59:58 UTC 2017


On Tue, 12 Sep 2017, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Tue, Sep 12, 2017 at 03:28:09PM +0000, Michal Wajdeczko wrote:
>> Our global struct with params is named exactly the same way
>> as new preferred name for the drm_i915_private function parameter.
>
> Preferred by some, perhaps not by others.
>
> I suspect Jani will be disappointed at losing the cute symmetry
> between the kernel command line and the code.

More than anything I'm annoyed at the gradual sneaking in of the "new"
i915, dubbing it as "preferred", without proper upfront
discussion. Regardless of the name clash, which is a minor detail.

We implicitly rely on dev_priv all over the place. If we decide to
rename, there's going to be a flag day with *massive* conflicts all over
the place. I seriously question the need or the benefits of renaming
dev_priv to i915. What purpose does it serve that helps us better
maintain the driver? How much developer time will be spent on resolving
conflicts and rebasing patches?

Everyone who's ever contributed more than a couple of patches to i915
*knows* what dev_priv means. Everyone who talks about it calls it
"dev_priv". In general, that's a good test for variable naming - how do
you talk about it spoken language? Seems like "i915" would create
ambiguity, while "dev priv" is unambiguous in the i915 context.

My gut feeling says no. I'm not convinced there's a benefit to be
had. Which kind of makes the patch at hand unnecessary churn too.

Honestly, I'd rather see a patch renaming all drm_i915_private pointers
back to dev_priv.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center


More information about the Intel-gfx mailing list