[Skiboot] [PATCH v2 08/14] console: add dummy_console_flush()
oohall at gmail.com
Tue Dec 20 19:06:22 AEDT 2016
On Tue, Dec 20, 2016 at 6:46 PM, Andrew Donnellan
<andrew.donnellan at au1.ibm.com> wrote:
> On 20/12/16 18:40, Oliver O'Halloran wrote:
>>> The other OPAL_CONSOLE_FLUSH call hasn't been removed yet, is having
>>> competing opal_call()s a defined thing?
>> No, there is always a single OPAL call handler. opal_register()
>> overwrites the existing handler at runtime.
> I'm referring to:
> ajd at ajd:~/code/skiboot$ gg "opal_call(OPAL_CONSOLE_FLUSH"
> core/console.c:opal_call(OPAL_CONSOLE_FLUSH, opal_console_flush, 1);
> core/console.c:opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1);
> I realise opal_register() overwrites the handler at runtime, but what
> exactly happens with multiple opal_call()s?
> This is of course moot as we fix it a few patches later.
Ah right. The macro itself spins up a struct which is inserted in a
special ELF section. When linking skiboot.elf it folds these sections
into an array that skiboot walks when filling out the OPAL call table
at boot. Whatever comes second in the table will be installed as the
handler, but the ordering in the table will depend on how the linker
> Andrew Donnellan OzLabs, ADL Canberra
> andrew.donnellan at au1.ibm.com IBM Australia Limited
More information about the Skiboot