Re: Polymorphic to_i915()

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Daniel Vetter <daniel@ffwll.ch> writes:

> [ text/plain ]
> On Mon, Apr 18, 2016 at 12:18:23PM +0300, Jani Nikula wrote:
>> On Fri, 15 Apr 2016, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > Final canvas for opinions for using a magic macro to reduce typing in
>> > the common operation of getting our drm_i915_private from the object.
>> >
>> > 	21 files changed, 333 insertions(+), 392 deletions(-)
>> >
>> > Not to mention the ease it makes for later patches to reduce the pointer
>> > dance.
>> 
>> I've expressed my reservations about this the last time.
>> 
>> My compromise proposal is this: let's add the to_i915()
>> "superconvenience macro", but let's not embed that into other
>> macros. Instead, move away from convenience macros in them, explicitly
>> requiring dev_priv.
>> 
>> This would make just one macro special, and would keep the rest less
>> surprising and "C-like". We already need dev_priv all over the place, so
>> I don't think having a local variable or an explicit to_i915() is a big
>> burden.
>
> Not much more to add, but I'm not strongly opinionated here really. But I
> do think that a trick of this magnitude needs much more enthusiastic
> support from a bunch of people before we can merge it.

This reduces boilerplate code. And compiler watches our back?
I fail to see the traps underneath, so I am leaning on the
supporting side.

Perhaps I need to reread the reservations post that Jani mentioned.

-Mika

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx