[PATCH 10/11] Add MPC8360EMDS board support
paulus at samba.org
Wed Oct 4 10:40:33 EST 2006
Dan Malek writes:
> > .... 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
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
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.
More information about the Linuxppc-dev