On Tue, Apr 21, 2020 at 10:32:45PM +0200, Sam Ravnborg wrote: > Hi > > > > Hm, I see the point of this (and the dev_field below, although I'd go > > > with dev_member there for some consistency with other macros using > > > offset_of or container_of), but I'm not sure about the dev_ prefix. > > > Drivers use that sometimes for the struct device *, and usage for > > > struct drm_device * is also very inconsistent. I've seen ddev, drm, > > > dev and base (that one only for embedded structs ofc). So not sure > > > which prefix to pick, aside from dev_ seems the most confusing. Got > > > ideas? > > > > We have pdev for the PCI device, dev for the abstract device, and things > > like mdev for struct mga_device in mgag200. So I'd go with ddev. I don't > > like drm, because it could be anything in DRM. I guess struct drm_driver > > is more 'drm' than struct drm_device. > > > > But all of this is bikeshedding. It's probably best to keep the patch > > as-is, and maybe rename variables later if we ever find consent on the > > naming. > > bikeshedding - I know. > But reading code is is quite natural for me that drm equals the central > drm_device data structure. Maybe thats because this was is in the code > I started looking at. > > So as an example: > > drm_err(drm, "bla bla\n"); > > This parses nicely and is easy to type and get right. > And matches nicely that drm_device => drm. > But bikeshedding - I will go to bed... > (Whatever is the conclusion we should not hold back the patch in > questions). Ok, since we can't agree on dev vs ddev vs drm vs something else I just left it as-is. We can always repaint this later on. Thanks everyone for comments and review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
