Dan Malek writes:

quoted

....   So you can boot the same kernel binary on
several boards, as long as the drivers are built in and the correct
device tree is used. Has everyone missed/forgotten that objective
completely?

That was never an objective when we started, although
it seems some people involved in the implementation
think it's the only objective.  It just happens to be a side
effect when convenient.

I tend to look at it not as a direct objective in itself for the
embedded platforms, but more as something that will just happen
naturally when the code is written well.

I also don't think it's the role of the upstream kernel sources to
support every single embedded board out there.  I think stuff should
be upstream if it is either (a) useful to a lot of people as-is, or
(b) useful as a starting point for making a kernel that will work on a
specific board.

Most of the embedded stuff falls into category (b), which means that
it needs to be understandable and reusable, rather than being
specifically optimized for a particular board.  That means that ifdefs
are evil, because they obfuscate the code.  Also, ifdefs are often a
sign that a driver is only written to support one instance of a
particular device, which is a limitation on its reusability - it will
have to be modified when someone makes a chip or board that has two of
its device on it.

I have no problem whatever with someone taking the upstream sources
and optimizing it to the nth degree for their particular embedded
board.  I don't think that's appropriate for the upstream sources
though.

The device-tree concept offers a way to make drivers more readable and
reusable, by separating out the board-specific configuration
information (thus reducing ifdefs) and by encouraging the style of
code that naturally copes with any number of device instances.

Now, we have something that is way more complex than
we initially thought was necessary, trying to describe nearly
everything addressable in the system instead of just the
internal memory map.  I suspect the software to attain

How does the "internal memory map" differ from "everything addressable
in the system"?  I think it is useful if the device tree describes the
non-discoverable devices in the system; we have never said the device
tree has to contain devices that the kernel can discover for itself,
such as PCI devices.

Highly configurable development/evaluation
boards running a single binary aren't high volume
products, and the additional resources required
by such software could ensure real products aren't
developed with PPCs.  We need to be sensitive
to this.

Leo Li had an interesting idea, which is a preprocessor that would
take kernel code written to use the device tree, plus the specific
device tree for a board, and emit a version of the code with
everything hard-coded.  That would assist with getting the
uber-optimized version that you want for a product.

Paul.