On Mon, 18 Jun 2018, Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: > Quoting Jani Nikula (2018-06-15 12:08:23) >> On Thu, 14 Jun 2018, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> 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@xxxxxxxxx> wrote: >> >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: >> >> >> >> >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> 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. Okay, we can continue to debate, but I've pushed this series in the mean time because it has review and by my judgement should not conflict much. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
