[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <561E6B22.1030204@cisco.com>
Date: Wed, 14 Oct 2015 07:48:02 -0700
From: Daniel Walker <danielwa@...co.com>
To: Rob Herring <robh@...nel.org>
Cc: Daniel Walker <dwalker@...o99.com>, xe-kernel@...ernal.cisco.com,
Frank Rowand <frowand.list@...il.com>,
Grant Likely <grant.likely@...aro.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH-RFC 6/7] drivers: of: ifdef out cmdline section
There's one last little wrinkle .. In the current setup the defconfig
CONFIG_CMDLINE="" is used as a default in case the device tree has
nothing in it. In my changes, there is no identical functionality. The
only similar thing I have is the the CONFIG_CMDLINE_APPEND="" . The main
difference is that in the current implementation CONFIG_CMDLINE=""
doesn't get added at all if there is a device tree bootargs, but with my
implementation this line would be added unconditionally. It would
represent a subtle change where people would have to add into the DT
bootargs something to override what might be in the default command line.
For example,
if a config has CONFIG_CMDLINE_APPEND="debug" then they would have to
add a "loglevel=7" into the DT bootargs to get back to normal. I
wouldn't think people would want "debug" as the default, but oddly
enough some of the configs do have this. Some of them also have default
ip address setting, nfsroot= settings, and loglevel= settings.
What are your thoughts on this ? I think using the append type default
makes more sense because it's actually setting up global defaults. The
current complete replacement scheme seems to set the stage for people to
make an entirely custom default for a single development machine, which
IMO doesn't make sense. However, I'm not sure what the intent is with
the current setup.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists