On Tue, 12 Sep 2017, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
