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
