Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Thu, Jul 13, 2023 at 05:39:36PM +0200, Uwe Kleine-König wrote:
> On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote:
> > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > > But even with the one-patch-per-rename approach I'd consider the
> > > renaming a net win, because ease of understanding code has a big value.
> > > It's value is not so easy measurable as "conflicts when backporting",
> > > but it also matters in say two years from now, while backporting
> > > shouldn't be an issue then any more.
> > 
> > You've rightly identified the conjecture in your statement. I've been
> > on both sides of the argument, having written/maintained drm code
> > upstream and cherry-picked changes to a downstream kernel. Perhaps
> > it's because drm's definition of dev is ingrained in my muscle memory,
> > or maybe it's because I don't do a lot of upstream development these
> > days, but I just have a hard time seeing the benefit here.
> 
> I see that my change doesn't immediately benefit those who are already
> at home in drivers/gpu/drm. So it's quite understandable that someone in
> a senior role (long time contributor or maintainer) doesn't see a big
> upside.
> 
> In contrast I think my change (with its indisputable cost) lowers the
> bar for new contributors to drm. IMHO that's something a maintainer has
> to have on their radar, too, and that's easily undervalued in my
> experience.

To be honest, DRM/KMS is quite a complex subsystem, so whether dev is
struct device or struct drm_device doesn't really do anything to move
the bar in either direction.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]