Date: Fri, 01 Dec 2017 17:47:04 -0800 (PST)
Subject: Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2
In-Reply-To: <CA+55aFxsmN4YhRUVe9Ehu36xKSJm0V3LFO7dT1Yk+bfHXa6wYA@mail.gmail.com>
CC: linux-kernel@vger.kernel.org, patches@groups.riscv.org,
        Olof Johansson <olof@lixom.net>
From: Palmer Dabbelt <palmer@sifive.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <mhng-99c81708-da13-43e4-a77d-1f2e6fdd885e@palmer-si-x1c4>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2631
Lines: 50

On Fri, 01 Dec 2017 16:47:16 PST (-0800), Linus Torvalds wrote:
> On Fri, Dec 1, 2017 at 4:39 PM, Palmer Dabbelt <palmer@sifive.com> wrote:
>>
>> I've been maintaining the various cleanup patch sets I have as their own
>> branches, which I then merged together and signed.  Each merge commit
>> has a short summary of the changes, and each branch is based on your
>> latest tag (4.15-rc1, in this case).  If this isn't the right way to do
>> this then feel free to suggest something else, but it seems sane to me.
>
> The individual branches with merges look fine.
>
> What I don't really like is how very recent they are. Many of the
> commits were done today, and thus clearly were never through the 0-day
> robot etc.
>
> I don't actually think the 0day robot does RISC-V at all, at least not
> yet, so in this case it probably doesn't really matter, but in general
> I _hate_ seeing pull requests that come in on a Friday afternoon where
> a lot of the  commits clearly happened that same day. It's simply a
> sign of things likely having been rushed, which in turn often leads to
> issues down the line.

The 0-day robot doesn't do RISC-V, but we're working on getting better CI 
infrastructure setup now that we're upstream.  Olof has started running builds 
through his builder, which is where many of the fixes came from.  

I think we're probably not quite ready for the 0-day robot yet:
* We still have an allmodconfig failure, but there's a patch out to fix that.
* binutils-2.29.1 and gcc-7.2.0 have a handful of bugs that were found when 
  pushing on Linux, the next releases should have fixes for these.  We have 
  backports, so this might not be a big deal.
* There's no way to boot the kernel in an easy to automated fashion.  Our QEMU 
  port is a WIP, and I currently test our port by swapping SD cards.  This 
  might not be a big deal, since the port as it stands can't do much in the way 
  of a boot test anyway.

I'll ping kbuild-all with a better subject and figure out the right thing to 
do.

> So the structure of the history looks ok, but I hope that "very
> recently made" is a one-time thing rather than a pattern. Ok?

OK, sorry about that.  It sounds like this is a good excuse to figure out how 
we're going to stage commits in RISC-V land -- I've been a bit unprepared for 
the pace of kernel development on RISC-V, I didn't think I'd see so many people 
poking around in our port so quickly :).

If you'd like, I can let these bake for a few days?  I don't mind if they don't 
get in until rc3.  I can either ping this pull request or send another one, 
whatever's easier for you is OK for me.