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:
signature.asc
Description: PGP signature
