[Intel-gfx] [PATCH 4/5] drm: Add support for subclassing struct drm_device

[David Herrmann]

Hi

On Thu, Jan 9, 2014 at 1:11 PM, Damien Lespiau <damien.lespiau at intel.com> wrote:
> On Wed, Jan 08, 2014 at 09:26:51PM +0100, Daniel Vetter wrote:
>> > So the parent structure is expected to have "struct drm_device" at
>> > offset 0? I'd rather like to see a "drm_dev_init()" alongside
>> > drm_dev_alloc() similar to device_initialize().
>>
>> Yeah, I think for subclassing we want drivers in charge to kmalloc the
>> entire thing and embedded struct drm_device wherever they please to do so.
>> Adding struct_size stuff all over the place still forces us through the
>> midlayer ...
>>
>> I'm trying to get there with my giant drm cleanup series (which contains
>> some of the same dev_priv_size cleanups like yours). Dunno whether it's
>> worth all to much to start embedding before we have that all ready since
>> imo the big value in demidlayering is that it allows us to fix up the
>> init/teardown sequence. That it also allows struct drm_device embedding is
>> kinda neat, but not my main goal.
>> -Daniel
>
> I'm not sure why would people want struct drm_device at a non-0 offset,
> but in any case, if Daniel is already looking into this, let's scrap
> that series. At least we know that it doesn't have to be a long term
> plan and we can do it as soon as we want.

In case you embed multiple objects in your parent device and both have
this requirement, you're screwed. Obviously, this only works if at
most one of them has a ref-count, but see for instance the gem+ttm
combinations, which embed both, gem_object and ttm_bo in their private
bo.

Besides, it's more about clean code here than functionality. The code
doesn't get more complicated if we remove the restriction so lets use
the cleaner way similar to "struct device".

Thanks
David