Hi Arnd,
On 05/08/2014 03:37 AM, Arnd Bergmann wrote:
On Wednesday 07 May 2014 16:06:49 Eric Nelson wrote:
On 05/07/2014 03:20 PM, Bjorn Andersson wrote:
On Wed, May 7, 2014 at 12:52 PM, Eric Nelson
<eric.nelson@xxxxxxxxxxxxxxxxxxx> wrote:
[...]
I still wonder about the choice of not allowing inclusion
of at least include/generated/autoconf.h.
Because what you just showed is the use case where you have 1 defconfig, build 1
zImage and then you can have a completely separate delivery of X number of
dtbs, all defining some variant of your original board.
All without recompiling, or even have the source available.
I agree that there's some benefit in being able to generate
different DTBs, and it's an advantage (size, speed) to customize
the .config as well.
When those clearly go together, it seems natural to define them as
such.
I've heard (and appreciate) the pointers about how to get
past our current issue(s), but what's the rationale
for not allowing the inclusion of autoconf.h and
conditionals in the DTS?
Is it a concern that things will become polluted and
hard to read?
You should be able to take any recent enough
Fedora/Debian/OpenSUSE/Ubuntu/OpenWRT kernel binary and install it on
all ARMv7 machines to get a working system, keeping your existing .dtb
file.
There are still a few issues to be worked out for that (e.g. some drivers
still can't be described in DT, and in some exceptional cases we break backwards
compatibility), but if the .dtb file depends on the kernel configuration,
it can never work, because the person building the kernel does not know
what hardware you have.
I think this highlights the difference in perspective.
Your comments (and Bjorn's) reflect a goal of being able to
build a single kernel/DTB that runs on multiple platforms.
My goal(s) are quite different, and center on building
an optimized system for a single purpose. Most customers
of our boards target a single app, and essentially
all of them use a sub-set of a board's functionality.
We encourage them to optimize their kernel configurations to
only include the meaningful pieces, which reduces boot time and
memory usage, log file spew, et cetera. The same goes for userspace
components: only include what you need.
(Re)building the kernel is not seen as an onerous task, as it's
a small piece of the puzzle.
I appreciate the feedback, and I don't want to make a big
deal of this. We have ways of achieving the goal, even if
I do think that judicious use of #ifdef would be helpful.
Regards,
Eric
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
