Michael Ellerman <m...@ellerman.id.au> writes: > Stewart Smith <stew...@linux.vnet.ibm.com> writes: >> Oliver O'Halloran <ooh...@gmail.com> writes: >>> diff --git a/arch/powerpc/include/asm/opal-api.h >>> b/arch/powerpc/include/asm/opal-api.h >>> index 0e2e57bcab50..cb9c0e6afb33 100644 >>> --- a/arch/powerpc/include/asm/opal-api.h >>> +++ b/arch/powerpc/include/asm/opal-api.h >>> @@ -167,7 +167,8 @@ >>> #define OPAL_INT_EOI 124 >>> #define OPAL_INT_SET_MFRR 125 >>> #define OPAL_PCI_TCE_KILL 126 >>> -#define OPAL_LAST 126 >>> +#define OPAL_SCRAPE_LOG 128 >> >> (another thought, along with the skiboot thoughts), I don't like the >> SCRAPE_LOG name so much, as it's more of a "hey linux, here's some log >> messages from firmware, possibly before you were >> involved"... OPAL_FETCH_LOG ? > > I'm not a huge fan of an interrupt followed by an opal call just to > fetch a single line of log. > > Can't we do something more like the existing msglog code, where we have > a ring buffer and then the interrupt just becomes "hey Linux you should > look at your ring buffer".
Yeah... that would probably be a bit better... Although that would mean we can only ever tell the running kernel what's in the ring buffer. We couldn't work out a way to (after kexec) resend important bits of info such as "we garded things out, your OCC didn't start and we trained everything at really slow speeds" -- Stewart Smith OPAL Architect, IBM.
