From: Daniel Walker on
On Fri, 2010-06-04 at 00:17 +0300, Tony Lindgren wrote:
> * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 23:30]:
> >
> > and now you'd be able to basically generate a OMAP3EVM .config file by
> > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
> > only have to select the parts that are specific for the EVM platform,
> > because the generic OMAP3 support would be picked by the Kconfig.omap3
> > file, which in turn would not have to worry about the generic ARM parts
> > etc.
> >
> > See?
>
> Sounds like a good improvment to me.

I was looking at this new defconfig added this merge window,
omap3_stalker_lks_defconig ..

diff -u arch/arm/configs/omap3_defconfig arch/arm/configs/omap3_stalker_lks_defconfig | diffstat
omap3_stalker_lks_defconfig | 850 +++++++-------------------------------------
1 file changed, 140 insertions(+), 710 deletions(-)

There's a lot of stuff that's different in there .. If I look through
it, there's stuff that's not related to OMAP , or even drivers. Like
Kprobes gets disabled over omap3_defconfig .

To me that's kind of messy .. It should really be just what the user
absolutely needs. I think we're able to get away with that now cause no
one cares enough to really read the defconfig and see what's going on.

Having stuff like that adds more flux.

Whatever scheme we go to would likely change that and people would
actually read what's going on. So we wouldn't be able to randomly have
Kprobes enabled in one config, and not enabled in another one. Or having
a debug config as one, then having a performance config for another.

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: Nicolas Pitre on
On Fri, 4 Jun 2010, Tony Lindgren wrote:

> * Russell King <rmk(a)arm.linux.org.uk> [100603 21:07]:
> > 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.

Eric Miao posted a patch series for that already.

> > - Be able to handle any multitude of V:P translations, including non-linear
> > alongside linear transations.

Some effort is being deployed at my $job to do that. Initially only the
linear translation will be supported, which should cover the vast
majority of the cases already. The odd targets will simply require a
build of their own like it is done today.

> > - Different PAGE_OFFSETs

Again, a majority of targets may simply share the default one.

> > - Different kernel VM layouts allowing for a variety of different ioremap
> > region sizes

VMALLOC_END should only need to become a per machine class variable
initialized at run time.

> Some of these could be handled by allowing building a seprate instance
> for each platform compiled in. Maybe we could set them up with symlinks.

We already have runtime selectable machine instances. Building multiple
machine class could extend on that.

> How about a minimal generic relocatable ARM kernel and then we load the
> platform support as a module from ramdisk? :)

Pity... Nah.

> > and so the list goes on...
>
> Yeah..

Like I said, there is an effort to gradually overcome those issues one
by one.


Nicolas
--
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: Kevin Hilman on
Russell King <rmk(a)arm.linux.org.uk> writes:

> 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...
>

- Support for ARMv5, v6 and v7 in the same kernel image.

On davinci, we've recently run into the problem where a new SoC in the
family is largely the same in terms of common HW blocks ands shared
peripherals with other davincis, but they upgraded from ARMv5 to
ARMv6. Attempting to build a single kernel that supports ARMv5 and
ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in
the same kernel.

Kevin
--
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: Paul Mackerras on
On Thu, Jun 03, 2010 at 01:31:07PM -0700, Linus Torvalds wrote:

> Now, the above is a _trivial_ one. And it's actually broken, because I
> should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT).

Seems to me that the brokenness of select is the main technical issue
stopping us getting rid of the defconfigs. If there was a way to tell
the Kconfig machinery "I want CONFIG_USB on, you figure out what has
to be enabled for that to make sense" then it would all work. But
that's a hard problem (and may possibly have multiple solutions).

Paul.
--
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: Benjamin Herrenschmidt on
On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
> 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.

Ok so multiple platforms in one kernel is a different subject and could
warrant a different thread. However it's interesting because we do that
quite well on powerpc :-)

(Note also that while the device-tree helps make it even easier, it's
not fundamentally necessary to achieve that goal).

> - Find someway to handle the wide variety of interrupt controllers.

We have a very nice and simple interrupt mapping scheme on powerpc that
makes that quite trivial along with the generic irq changes that went in
a couple of years ago (which we mostly based on ARM iirc).

We have a structure that define an interrupt numbering domain (which can
be associated 1:1 with a given controller but doesn't have to), and
simple APIs to allocate "linux" interrupt numbers associated with a
given domain/HW number pair. From there, we support multiple domains,
arbitrary layout and cascades, etc...

> - Be able to handle any multitude of V:P translations, including non-linear
> alongside linear transations.

For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore
spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic
patching would do nicely here though it's problematic with XIP kernels
(though my understanding is that those are getting less common).

> - Different PAGE_OFFSETs

Does this have to be a per SoC or mach family ? Users can change
PAGE_OFFSET on powerpc to change the user/kernel split (for example in
order to get more ioremap space or avoid turning on HIGHMEM) but it's in
the domain of the config and a kernel with a lower PAGE_OFFSET can
always boot all platforms even those that don't require it.

Alternatively, you can always try to do like we do on ppc64 with fully
runtime relocatable kernels :-)

> - Different kernel VM layouts allowing for a variety of different ioremap
> region sizes
>
> and so the list goes on...

That's quite easily done at runtime.

> > 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.

Cheers,
Ben.


--
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/