Re: [PATCH 0/3] Add support for OMAP35x processors

[David Brownell <david-b@pacbell.net>]

On Friday 09 January 2009, Aguirre Rodriguez, Sergio Alberto wrote:
> >  comment "OMAP Board Type"
> >       depends on ARCH_OMAP2 || ARCH_OMAP3
> > 
> > @@ -107,7 +155,7 @@ config MACH_OMAP_2430SDP
> > 
> >  config MACH_OMAP_LDP
> >       bool "OMAP3 LDP board"
> > -     depends on ARCH_OMAP3 && ARCH_OMAP34XX
> > +     depends on ARCH_OMAP3 && ARCH_OMAP34XX && !ARCH_OMAP35XX
> > 
> >  config MACH_OMAP2EVM
> >       bool "OMAP 2530 EVM board"
> > @@ -115,11 +163,11 @@ config MACH_OMAP2EVM
> > 
> >  config MACH_OMAP_3430SDP
> >       bool "OMAP 3430 SDP board"
> > -     depends on ARCH_OMAP3 && ARCH_OMAP34XX
> > +     depends on ARCH_OMAP3 && ARCH_OMAP34XX && !ARCH_OMAP35XX
> > 
> >  config MACH_OMAP3EVM
> >       bool "OMAP 3530 EVM board"
> > -     depends on ARCH_OMAP3 && ARCH_OMAP34XX
> > +     depends on ARCH_OMAP35XX
> > 
> >  config MACH_OMAP3_BEAGLE
> >       bool "OMAP3 BEAGLE board"
> 
> Question to all,
> 
> Why don't making above options as choice.. endchoice.

Because that completely breaks "multi-OMAP" builds.
Having kernels build (and work!) with multiple boards
has been a goal for some time now.

Switching that stuff to choice...endchoice would be
a major regression.  I wouldn't merge such a patch.


> Or is there any case that multiple boards are compiled at once? 
 
Yes, it's routine to build kernels that work with
multiple boards.  Example, mine work on Beagle,
Overo, and SDP.

Why do this?  Several reasons, all of which boil
down to better quality code.  The most obvious
ones are being able to build-test more systems
in the same amount of time ... and then being
able to run-test them without needing to waste
any time worrying if the behavioral change was
due to some odd Kconfig glitch, or is just a bug
to fix in the code.

The more subtle issues have to do with the
various changes that happen to make that
work well.  Example, board specific #ifdefs
in code start to vanish ... which is good,
since they hide lits of problems, and are
nasty coding style regardless.  Sometimes
getting rid of such #ifdeffery highlights
a much better code structure.

Ditto CPU-specific #ifdeffery, of the type
which these patches add.  Fix them so they
don't add #ifdeffery like that, and they
will be a lot better accepted...

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html