[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mhng-fa7412d4-47d2-47e5-b36b-a237dfb04c9d@palmer-si-x1c4>
Date: Wed, 04 Oct 2017 17:21:42 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: Arnd Bergmann <arnd@...db.de>, sfr@...b.auug.org.au,
Olof Johansson <olof@...om.net>
CC: linux-kernel@...r.kernel.org, patches@...ups.riscv.org,
robh+dt@...nel.org, mark.rutland@....com, albert@...ive.com,
yamada.masahiro@...ionext.com, mmarek@...e.com,
will.deacon@....com, peterz@...radead.org, boqun.feng@...il.com,
oleg@...hat.com, mingo@...hat.com, devicetree@...r.kernel.org
Subject: Re: RISC-V Linux Port v9
On Tue, 26 Sep 2017 23:08:02 PDT (-0700), Arnd Bergmann wrote:
> On Tue, Sep 26, 2017 at 6:56 PM, Palmer Dabbelt <palmer@...belt.com> wrote:
>> As per suggestions on our v8 patch set, I've split the core architecture code
>> out from our drivers and would like to submit this patch set to be included
>> into linux-next, with the goal being to be merged in during the next merge
>> window. This patch set is based on 4.14-rc2, but if it's better to have it
>> based on something else then I can change it around.
>
> -rc2 is good, just don't rebase it any more. I'd suggest that at the point this
> becomes part of linux-next, you stop modifying the patches further and
> move to adding any additional changes as patches on top.
Sounds good. I've gotten a kernel.org account now, so I've gone ahead and
signed a "for-linux-next" tag that contains this patch set. I'm going to treat
what's here as an official pull request into linux-next and therefor I won't be
rewriting history any more. If I understand everything correctly, once I'm in
linux-next I'm meant to update that tag with commits that are ready to go?
Is there anything further I should do in order to get that tag merged into
linux-next?
>> * I cleaned up the defconfigs -- there's actually now just one, and it's
>> empty. For now I think we're OK with what the kernel sets as defaults, but
>> I anticipate we'll begin to expand this as people start to use the port
>> more.
>
> The kernel defaults are not really as sensible as one would hope. Maybe
> go through your previous defconfig once more and pick up the items that
> made sense.
I was a bit surprised at the defaults: for example, I'd expect things like
CONFIG_PCI and CONFIG_NET to be enabled by default. I guess I just assumed
that since technically we have a working kernel without those that it was fine
to just stick with the defaults. Looking at our old defconfig, I'd pick
CONFIG_PCI=y
CONFIG_NAMESPACES=y
CONFIG_NET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_DEVTMPFS=y
CONFIG_EXT2_FS=y
CONFIG_TMPFS=y
does that seem reasonable?
Powered by blists - more mailing lists