[PATCH 00/12][RFC] Intial Kconfig Fragment Demo

[Amit Kucheria]

On Wed, Mar 9, 2011 at 10:57 AM, Andy Green <andy at warmcat.com> wrote:
> On 03/09/2011 08:51 AM, Somebody in the thread at some point said:
>
> Hi -
>
>>> Panda is OMAP4 and the other two are OMAP3 AIUI, I am aware they are all
>>> under "OMAP2+" in the kernel, but there are really significant
>>> differences
>>> from configuration point of view like SMP or not.
>>>
>>> How is that handled with the same config?
>>
>> One can build a single kernel binary that runs on OMAP2/3/4 platforms
>> from the mainline kernel. That has been the main requirement from the
>> maintainer to add new board support. Everything under mach-omap2 and
>> plat-omap is written for runtime detection of features.
>
> I know it well.  However -->
>
>> However, last I looked, there were problems with the ARM locking
>> primitives being patched at runtime. So it prevented SMP-on-UP
>> kernels, that is, SMP had to be turned off. But that will eventually
>> get fixed so you could have a SMP kernel running on a UP system. This
>> is how x86 does it today.
>
> I take it this magic of SMP or not is hidden in this config layering scheme
> you mentioned and it isn't really using the same config for say igep0020 and

No, it is in the black depths of ARM assembly and TBH, it is voodoo to
me. Nothing to do with kernel config as such. The SMP kernel, at
runtime, (binary) patches itself to convert locking primitives to
no-ops in the UP case. Or something to the effect.

> Panda.  In any event, there's a performance tradeoff running SMP kernel on
> uniprocessor to consider too.

Apparently, with this one-time patching (per boot) there isn't such a tradeoff.

> Absolutely that's the future... in fact the bootloader should work the same
> way with one per-arch bootloader that detects what it is running on at
> runtime, and at that point device-specific point hwpacks become very thin or
> non-existent and there's an epic reduction in how many different binaries
> are needed to support many boards.

I can hear the collective sighs of appreciation from distribution maintainers :)