public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 4/5] drm: Add support for subclassing struct drm_device
Date: Wed, 8 Jan 2014 21:26:51 +0100	[thread overview]
Message-ID: <20140108202651.GW4770@phenom.ffwll.local> (raw)
In-Reply-To: <CANq1E4QPmNA8RFUZuxDD3HUzUHipkg3MuY-2fZ094k74e+2Vkg@mail.gmail.com>

On Wed, Jan 08, 2014 at 08:01:19PM +0100, David Herrmann wrote:
> Hi
> 
> On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau <damien.lespiau@intel.com> wrote:
> > Currently, drivers are expected to allocate private data and attach it
> > to dev_private in struct drm_device.
> >
> > This has the unfortunate property to require driver code to juggle
> > between the pointer to struct drm_device and dev->dev_private instead of
> > using the same pointer if they could embed the device structure.
> >
> > This patch enables drivers to declare the size of the device structure
> > they want DRM core to create for them.
> >
> > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
> > ---
> >  drivers/gpu/drm/drm_stub.c | 8 +++++++-
> >  include/drm/drmP.h         | 8 ++++++++
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> > index 98a33c580..161dd9a 100644
> > --- a/drivers/gpu/drm/drm_stub.c
> > +++ b/drivers/gpu/drm/drm_stub.c
> > @@ -433,8 +433,14 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> >  {
> >         struct drm_device *dev;
> >         int ret;
> > +       size_t device_struct_size;
> >
> > -       dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> > +       if (driver->device_struct_size)
> > +               device_struct_size = driver->device_struct_size;
> > +       else
> > +               device_struct_size = sizeof(*dev);
> 
> How about a:
> WARN_ON(driver->device_struct_size < sizeof(*dev))
> 
> > +
> > +       dev = kzalloc(device_struct_size, GFP_KERNEL);
> 
> 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-01-08 20:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 18:31 [RFC] Subclassing struct drm_device Damien Lespiau
2014-01-08 18:31 ` [PATCH 1/5] drm: Remove unnecessary dev_priv_size initializations to 0 Damien Lespiau
2014-01-08 18:31 ` [PATCH 2/5] drm: Remove dev_priv_size from struct drm_buf Damien Lespiau
2014-01-08 18:31 ` [PATCH 3/5] drm: Rename dev_priv_size to buf_priv_size Damien Lespiau
2014-01-08 18:31 ` [PATCH 4/5] drm: Add support for subclassing struct drm_device Damien Lespiau
2014-01-08 19:01   ` David Herrmann
2014-01-08 20:26     ` Daniel Vetter [this message]
2014-01-09 12:11       ` Damien Lespiau
2014-01-09 12:18         ` David Herrmann
2014-01-08 18:31 ` [PATCH 5/5] drm/i915: Make struct drm_i915_private a subclass of " Damien Lespiau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140108202651.GW4770@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox