Re: [PATCH 01/59] drm: Add devm_drm_dev_alloc macro

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux