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). Sam _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
