[Intel-gfx] [PATCH] drm/i915: Agnostic INTEL_INFO

Chris Wilson chris at chris-wilson.co.uk
Wed Jul 2 15:17:24 CEST 2014


On Wed, Jul 02, 2014 at 02:12:08PM +0100, Damien Lespiau wrote:
> On Wed, Jul 02, 2014 at 03:57:08PM +0300, Jani Nikula wrote:
> > On Wed, 02 Jul 2014, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > Adapt the macro so that we can pass either the struct drm_device or the
> > > struct drm_i915_private pointers and get the answer we want.
> > 
> > Polymorphism?! :o
> > 
> > >    text    data     bss     dec     hex filename
> > > 8138307 1234176  679936 10052419         996343 vmlinux.before
> > > 8137591 1234176  679936 10051703         996077 vmlinux.after
> > >
> > > 700 bytes of code saving and peace of mind. Just don't look at the
> > > macro.
> > 
> > I did. I think I need to get new glasses now.
> > 
> > I haven't yet decided whether this is really hideous or really
> > cool. Maybe both.
> 
> I think I like my version (or a variation of the theme)
> http://lists.freedesktop.org/archives/dri-devel/2014-January/051496.html
> better, but after Daniel comment I abandoned the effort to not conflict
> with his work.

Subclassing is the way forward. I think this is merely a stepping stone
to make the code neater in the short term.
 
> I don't believe this moved on at all since, oh well.
> 
> I would think the explicit cast from __I915__(), __DRM__() are not
> needed?

They are all there to keep the compiler happy, CPP is not a true macro
system after all.
 
> Maybe adding a BUILD_BUG_ON() checking the sizes of the 2 structures
> would let us sleep at night. drm_device is unlikey to catch up any time
> soon though.

Indeed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list