On Thu, 17 Mar 2016, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > There is a lot of ways to get to our dev_priv depending on which > object is at hand and often what was chosen by the developer. > > We can make to_i915() accept different pointers by using compile > time magic. Like: > > dev_priv = to_i915(request); > dev_priv = to_i915(engine); > dev_priv = to_i915(ctx); > dev_priv = to_i915(dev); > dev_priv = to_i915(guc); > dev_priv = to_i915(device); > > If an unknown pointer is passed to the function it will cause > a compile time failure. > > Main advantage is that with this in place we could add and > remove shourtcuts to dev_priv from supported structures easily > and without touching the code which uses it. If we wanted to > fiddle with the balance of structure sizes and number of pointer > dereferencing for example. And it makes the code a bit tidier > and uniform. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > -- > However the churn is huge so I don't really think this is a > must have. The "magic" __I915__() macro was added to support a transition from using dev pointer to using dev_priv pointer. I like the transition, and we slowly keep doing it. IMO there have been two problems with that. First, the transition is slow, because there's nothing forcing us to switch. This was expected, as we explicitly didn't want a huge patch (like this). Second, it appears to *still* confuse people after over a year that you can pass either type of pointer to the macros in C. I object to this patch both because it's huge (and I'll get my fair share of the conflicts) and, more importantly, because it promotes an appearance of a sort of dynamic typing in a statically typed language. The latter contains an element of surprise to the programmer, and surprising is not a quality I want to associate with code. I think I'd rather promote a sensible set of T_to_i915() macros for cleanly doing the conversion from various types we often use, and slowly keep transitioning. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
