Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

From: "Matt Sealey" <matt@genesi-usa.com>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linux-embedded@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Stefan Roese <sr@denx.de>, Wolfgang Denx <wd@denx.de>,
	Grant Erickson <gerickson@nuovations.com>
Subject: Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Date: Tue, 25 Nov 2008 13:01:15 -0600	[thread overview]
Message-ID: <b5e2fc790811251101t1c3b9ca9yaa6d75087190f10f@mail.gmail.com> (raw)
In-Reply-To: <20081125135519.038abf23@zod.rchland.ibm.com>

[-- Attachment #1.1: Type: text/plain, Size: 1076 bytes --]

On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com>wrote:

> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <matt@genesi-usa.com> wrote:
>
> > Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> > property(ies), perhaps something in the
> > /chosen node that U-Boot etc. can then fill out?
>
> I don't think that's a nitpick.  It's a fundamental change in how this
> would all work.  However, I do think you're generally right.
>
> Perhaps not /chosen, but maybe something like /rtas or /firmware, etc.
>
> josh

I think the best place is chosen, with things like stdin, stdout etc. - this
is where you generally go and dump weird little variables which need to be
passed in for early boot. You could consider the log buffer a kind of
stdin/out variation.

I don't think it needs a whole new device tree node just for two memory
locations.. is the support really worth a compatible property, etc. to
differentiate between different operating modes?

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

[-- Attachment #1.2: Type: text/html, Size: 1616 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev