Timur Tabi wrote:
On Thu, Oct 9, 2008 at 10:59 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
If you really want to build a single-cpu single-board kernel, disable CHRP
and PMAC for those board configs, but the default definitely should be to
enable them all within reason
The problem is that this is inconsistent with most Kconfig options.
Last I heard, the kernel community generally frowns on "default y" in
Kconfig options.
I'm waiting for someone to explain to me what's so special about CHRP
and PMAC that these two platforms should be enabled by default, when
all other PowerPC platforms are disabled by default.
This is what I see in menuconfig when I create a fresh .config for PowerPC:
│ │ [*] Common Hardware Reference Platform (CHRP) based machines (NEW)
│ │ [ ] Freescale MPC5121E ADS (NEW)
│ │ [ ] Generic support for simple MPC5121 based boards (NEW)
│ │ [ ] 52xx-based boards (NEW)
│ │ [*] Apple PowerMac based machines (NEW)
│ │ [ ] 82xx-based boards (PQ II) (NEW) --->
│ │ [ ] 83xx-based boards (NEW) --->
│ │ [ ] 86xx-based boards (NEW) --->
│ │ [ ] Embedded 6xx/7xx/7xxx-based boards (NEW)
CHRP and PMAC aren't following the rules that everyone else is following. Why?
Because they are by far the historically most common configuration, and
still in production as the defacto standard PowerPC system configuration.
IBM blades etc. with SLOF will boot up as a CHRP-ish system, as well as the
Efika and Pegasos and anything else Genesi produces. Since Linux distributions
generally do not support tiny embedded boards, you can imagine why it's
disabled by default, but there's no reason it can't be ENABLED by default
and turned off by a distribution, the same way it can't be enabled by
default and turned off by YOU (compare and contrast having to manually
select which board you want to build for every time).
But, turning them all on would not matter. You would build a kernel for
every one and a device tree for every one increasing your build time a
bit for a default kernel, but you would be guaranteed to get a kernel
binary somewhere in the tree that would work on all of them :)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
