[Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types

[Joonas Lahtinen]

Quoting Jani Nikula (2018-06-15 12:08:23)
> On Thu, 14 Jun 2018, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote:
> >> On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi at gmail.com> wrote:
> >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula <jani.nikula at intel.com> wrote:
> >> >>
> >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> wrote:
> >> >> > On 12/06/2018 10:19, Jani Nikula wrote:
> >> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that shouldn't
> >> >> >> conflict much with in-flight patches.
> >> >> >>
> >> >> >> The trouble with mixed use is that it's inconsistent, and any remaining C99
> >> >> >> types will encourage their use. We could at least do the low hanging fruit?
> >> >> >
> >> >> > Ack from me. Doesn't seem so big to cause much pain.
> >> >> >
> >> >> > When you say low-hanging fruit, that implies you only dealt with a
> >> >> > particular class of occurrences?
> >> >>
> >> >> I meant the files which don't have massive amounts of C99 types and
> >> >> aren't under active development right now. I just wanted to avoid
> >> >> trouble for starters. ;)
> >> >
> >> > If using kernel types is where we want to go (which I agree with),
> >> > maybe it would be better to have a single conversion rather than
> >> > several small ones as we are doing with dev_priv -> i915? This allows
> >> > in-flight-but-not-yet-sent patches to easily keep up with the changes
> >> > rather than conflicting every other rebase.
> >> 
> >> I'm thinking we can do a lot of changes without conflicting anything or
> >> very little. At least for starters before the sudden ripping off the
> >> band-aid.
> >
> > I'm with Lucas. I'd prefer one single massive move than many small ones.
> > Easier for the internal maintenance. We fix it only once and not one per
> > day for months and months like dev_priv/i915 case.
> 
> For everything else, I believe smaller patches are easier. For example,
> who is going to review the massive change? Halt everything until it's
> reviewed and merged? For merge conflicts I think git can do a better job
> of managing the rerere with piecemeal changes. Internal is not the only
> consideration.

I'm somewhere in the middle, but I have to agree changing everything with
one patch would be bit too overwhelming for review.

Regards, Joonas