[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJKBeAgaHQJwOL9G2qLbQSh32L5LtN+cSUgn5sV_P8How@mail.gmail.com>
Date: Tue, 30 Mar 2021 15:13:04 -0500
From: Rob Herring <robh@...nel.org>
To: Daniel Walker <danielwa@...co.com>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
Will Deacon <will@...nel.org>,
Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>,
Andrew Morton <akpm@...ux-foundation.org>,
X86 ML <x86@...nel.org>,
"open list:MIPS" <linux-mips@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
xe-linux-external@...co.com, Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker <danielwa@...co.com> wrote:
>
> On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote:
> > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker <danielwa@...co.com> wrote:
> > >
> > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > > >
> > > > Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
> > > >
> > > > Let's only provide once CMDLINE as of today, and ask the user to select
> > > > whether he wants it appended or prepended or replacee. Then no need to
> > > > change all existing config to rename CONFIG_CMDLINE into either of the new
> > > > ones.
> > > >
> > > > That's the main difference between my series and Daniel's series. So I'll
> > > > finish taking Will's comment into account and we'll send out a v3 soon.
> > >
> > > It doesn't solve the needs of Cisco, I've stated many times your changes have
> > > little value. Please stop submitting them.
> >
> > Can you please outline what those needs are which aren't met?
>
> append AND prepend at the same time on all architectures. Christophe doesn't
> understand the need, and hence tries to minimize the feature set which is
> incompatible with Cisco needs and all the other out of tree users.
Okay, but that's never been a feature in upstream. For upstream, we
refactor first and add features 2nd. In this case, the difference is
largely the kconfig and it would be better to not change the options
twice, but that's not a blocker for taking the refactoring. You won't
find a maintainer that's going to take adding a feature over cleanups
and unification.
Rob
Powered by blists - more mailing lists