From: Tony Lindgren on
* Linus Torvalds <torvalds(a)linux-foundation.org> [100603 17:48]:
>
> So I _think_ whatever "mach-xyz" file _should_ do something like
>
> # Kconfig file for OMAP4ABCXYZ chip
>
> .. set the particulars for this _particular_ chip,
> ie select the particular drivers on this chip ..
>
> include "chip-family-details" (ie maybe "base OMAP details")
>
> include "architecture-family-details" (ie ARM Kconfig)
>
> see? Not one flat file, and very much not something generated.
>
> And I actually suspect we could do it with our current Kconfig file model.
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have
> basically a
>
> choice
> prompt "ARM platform"
>
> config ARM_PLATFORM_OMAP
> bool PLATFORM_OMAP
>
> config ARM_PLATFORM_MSM
> bool PLATFORM_MSM
> ...
> endchoice
>
> if ARK_PLATFORM_OMAP
> include "Kconfig.omap" # this will further have choices for OMAP versions
> elif ARM_PLATFORM_...
>
> and then the individual "Kconfig.platform" files could select certain
> options, and then do a "include Kconfig.cpu" which would actually be the
> _current_ top-level arch/arm/Kconfig.

Some of this work has been already done like I responded in the other
thread. So we could use the current omap3_defconfig for omap2, 3 & 4
with some more work. Then do the same thing for omap1. That would cut
it down by total of 38 defconfigs.

Compiling in multiple ARM platforms is trickier, we would have to get
rid of the duplicate defines like NR_IRQS, then have some common clock
framework etc. Then figure out some way to get rid of Makefile.boot.
Russell probably has some other things in mind that would have to be
changed to make this happen.

> And I don't think we can get there from here unless I at some point say "I
> just removed the xyz_defconfig files", at which point people will curse me
> and stumble about until they actually come up with something better.
>
> Of course, if the ARM people do something proactive like the above
> _before_ I remove the defconfig files, I won't complain.

Whenever you feel like it, please just go ahead and do:

$ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm

That way maybe you can wait a bit longer for the other defconfigs
and as an extra bonus I won't get flamed for removing these omap
defconfigs ;)

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King on
On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> Compiling in multiple ARM platforms is trickier, we would have to get
> rid of the duplicate defines like NR_IRQS, then have some common clock
> framework etc. Then figure out some way to get rid of Makefile.boot.
> Russell probably has some other things in mind that would have to be
> changed to make this happen.

- Find someway to handle the wide variety of interrupt controllers.
- Be able to handle any multitude of V:P translations, including non-linear
alongside linear transations.
- Different PAGE_OFFSETs
- Different kernel VM layouts allowing for a variety of different ioremap
region sizes

and so the list goes on...

> That way maybe you can wait a bit longer for the other defconfigs
> and as an extra bonus I won't get flamed for removing these omap
> defconfigs ;)

Note that Linus is talking about removing all but one or two ARM
defconfigs - which means your omap3_defconfig will probably be
eventually culled.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King on
On Thu, Jun 03, 2010 at 07:48:18AM -0700, Linus Torvalds wrote:
> So I _think_ whatever "mach-xyz" file _should_ do something like
>
> # Kconfig file for OMAP4ABCXYZ chip
>
> .. set the particulars for this _particular_ chip,
> ie select the particular drivers on this chip ..
>
> include "chip-family-details" (ie maybe "base OMAP details")
>
> include "architecture-family-details" (ie ARM Kconfig)
>
> see? Not one flat file, and very much not something generated.

Umm...

> And I actually suspect we could do it with our current Kconfig file model.
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have
> basically a
>
> choice
> prompt "ARM platform"
>
> config ARM_PLATFORM_OMAP
> bool PLATFORM_OMAP
>
> config ARM_PLATFORM_MSM
> bool PLATFORM_MSM
> ...
> endchoice

Umm. I don't think you've actually looked at the Kconfig files if you're
writing this, because that's precisely what we already do.

arch/arm/Kconfig has a big choice statement in it to select the machine
class, and then it sources the individual arch/arm/*/Kconfig files,
which are themselves wrapped in a

if FOO

foo's options

endif

It's not one huge big "let's source everything and hope people ignore
options which don't apply to their platform" that you seem to be implying
we are doing.

The big problem with doing away with the defconfig files is more to do
with what happens _outside_ of arch/arm.

At one time, I was phasing IDE out, and didn't want to see the "IDE"
configuration options on platforms which either never had IDE support
or had had IDE support removed - unfortunately I was overruled by the
IDE/ATA developers and the conditionals we had went away.

That's just one instance, but consider when you're presented with
thousands of driver and filesystem configuration options as is the
case with modern kernels. How do you find the few options you need
to get to a point that the kernel you've built is actually useful?

Anyway, I thought we were discussing _defconfig_ files, not Kconfig
files...

What we _could_ to is introduce a:

config STD_CONFIG
bool "Enable me to generate a standard configuration for your platform"

and then have platforms conditionally select everything that's
appropriate for their use. That provides a way to avoid the ages old
issue of select forcing options on, but the user still being presented
with the option and being told the only possible value for it is 'y'.

And yes, it _is_ necessary - because if you want to turn off something
on the platform - eg, you're not using MMC and MMC fails to build -
you can still end up with a working configuration at the end of the
day.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on
On Thu, 2010-06-03 at 19:10 +0100, Russell King wrote:

> config STD_CONFIG
> bool "Enable me to generate a standard configuration for your platform"
>
> and then have platforms conditionally select everything that's
> appropriate for their use. That provides a way to avoid the ages old
> issue of select forcing options on, but the user still being presented
> with the option and being told the only possible value for it is 'y'.
>
> And yes, it _is_ necessary - because if you want to turn off something
> on the platform - eg, you're not using MMC and MMC fails to build -
> you can still end up with a working configuration at the end of the
> day.

Check out the SAT solver link I quoted in the prior email.. That sounds
like a really interesting solution. The defconfigs would ultimately hold
just what's unique to a given board, then the solver would figure out
what to else to enable just from those unique properties.

So we would still have defconfigs , but they would not have loads of
duplication like they do now.

I don't see how we can do without defconfigs altogether tho. I mean , if
you want to run a Beagle board or a Nexus one we can't just give the
users a slim ARM config and let them troll through 1000's of drivers
trying to find just those ones that work on their given board.

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on


On Thu, 3 Jun 2010, Russell King wrote:
>
> Umm. I don't think you've actually looked at the Kconfig files if you're
> writing this, because that's precisely what we already do.

... but if you do this _right_, then the defconfig files would be
unnecessary.

That's my point. If you are right, then I can remove the defconfig files
entirely. Are you ready for that?

And if you aren't ready for that, then what was the point of your email?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/