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

[John Rigby]

On Fri, Mar 11, 2011 at 3:32 AM, Dave Martin <dave.martin at linaro.org> wrote:
> 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?

linux-linaro-omap runs on omap[34] and has for most of this cycle.
Currently CONFIG_SMP and CONFIG_SMP_ON_UP are both on.

OMAP4 has had some glitches, first no display then broken display.
The next release has display with blue text just like the Ubuntu
kernel:).  Since linux-linaro-omap is based on upstream or headed
upstream patches it does not have all the functionality of the Ubuntu
ti-omap4 kernel.

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