On Thu, Oct 5, 2017 at 2:21 AM, Palmer Dabbelt [off-list ref] wrote:

On Tue, 26 Sep 2017 23:08:02 PDT (-0700), Arnd Bergmann wrote:

quoted

On Tue, Sep 26, 2017 at 6:56 PM, Palmer Dabbelt [off-list ref] wrote:

quoted

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?

Please be aware that Stephen has announced that there won't be any
linux-next trees until the end of the month, which will be the kernel
summit in Prague.

https://lkml.org/lkml/2017/9/29/13

It may be worth sending him a request to include your tree when
he returns, I assume there will be a long email backlog and he might
miss it otherwise.

quoted

quoted

 * 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.

Some of the defaults are really pretty random and are only like this for
historic reasons.

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?

Mostly yes, but please disable ext2 and use ext4 instead.

       Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html