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

[Dave Martin]

On Wed, Mar 9, 2011 at 9:13 AM, Andy Green <andy at warmcat.com> wrote:
> On 03/09/2011 09:04 AM, Somebody in the thread at some point said:
>
>>> 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.
>
> Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess this
> is to do with what you mentioned.
>
>>> 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.
>
> OK thanks for the explanation.

SMP-on-UP appears to be fully working nowadays.  We currently don't
build a single SMP kernel for omap4 and omap3, but I've been playing
with that and it's been shown to work.  Does anyone know whether we're
planning to move to a single OMAP kernel?  Has anyone measured the
performance delta?

In principle, we could make this move; but there could be issues I'm
not aware of.

Note that the SMP-on-UP support is fairly minimal -- only those things
which literally will fail on UP are patched out.

Cheers
---Dave

>
>>> 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 :)
>
> ^^
>
> -Andy
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>