Hi,
On Thu 13 Jul 23, 14:05, Jani Nikula wrote:
> On Thu, 13 Jul 2023, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> > If you say you consider the idea bad or too costly to implement, that's
> > fine. But pointing to other areas that are bad shouldn't be a relevant
> > reason to shoot down this effort.
>
> I did not point to other places saying they're "bad". That's your
> opinion, not mine. I don't think the drm usage of the dev name is bad,
> and I pointed out drm is not alone in using it.
For what it's worth, my personal rule is to use a prefix to dev if there
are multiple variables of a whatever-called-device type, and just call it dev if
there is nothing else about a device.
So as expressed before, I also don't see the problem with drm_device being
called dev, which I find a lot more descriptive than drm.
There's a general pattern that is usually applied to devices (not just drm):
- struct driver_specific_dev
- struct subsystem_specific_dev
- struct device
So I always find it quite clear which type of device we are talking about
when accessing a dev member of one of these. Suggesting that the name dev is
bad for something that refers to the subsystem-specific dev in some
subsystem-specific object kind of implies that it would make sense to have
a struct device called dev in that structure, which adds more confusion as this
is generally not the case.
So I would also be happier without this change.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
