All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Mike Waychison <mikew@google.com>
Cc: torvalds@linux-foundation.org, San Mehat <san@google.com>,
	Aaron Durbin <adurbin@google.com>,
	Duncan Laurie <dlaurie@google.com>,
	linux-kernel@vger.kernel.org, Tim Hockin <thockin@google.com>
Subject: Re: [PATCH v1 0/6] google firmware support
Date: Wed, 26 Jan 2011 10:47:29 +0800	[thread overview]
Message-ID: <20110126024729.GC28283@kroah.com> (raw)
In-Reply-To: <AANLkTim_KmmtAULeeBBsoz_BkxhbQLg24PK_pfPQiLtE@mail.gmail.com>

On Tue, Jan 25, 2011 at 11:58:27AM -0800, Mike Waychison wrote:
> On Mon, Jan 24, 2011 at 7:01 PM, Greg KH <greg@kroah.com> wrote:
> > On Mon, Jan 24, 2011 at 04:24:34PM -0800, Mike Waychison wrote:
> >>
> >>    - [5] prepares for [6] by introducing prepend_to_dmesg() which
> >>      allows drivers to prepend pre-kernel messages to the dmesg at
> >>      bootup.
> >
> > That seems "rude".  Why can't you just pick out from the kernel log the
> > data you need when it gets printed?  This seems like you feel your code
> > should always get a "First Post!" message.
> 
> Well, the use case we have is that we prepend all the bios output (and
> anything emitted by option roms and boot loaders via int 10h).  This
> typically runs in the 100+ lines of output.
> 
> Basically, everything the user sees on the console after power up is
> available to him in the dmesg.  We did this out of convenience as it
> makes for a good looking log :)

That's a nice goal, but I don't think the kernel log is the proper place
for this.

> That said, it's dmesg, and we don't build automation on anything in
> there if we can help it.  I can move this memory console dump
> elsewhere (/sys/firmware/log ?)

Yes, /sys/firmware/log would be a great place for it.  Make it a binary
sysfs file, and just dump the firmware data right into it, not having
the kernel do anything with it at all.

Oh, and document the thing in Documentation/ABI please, so that other
platforms can take advantage of this interface as well in the future.

nice idea,

greg k-h

      reply	other threads:[~2011-01-26  2:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25  0:24 [PATCH v1 0/6] google firmware support Mike Waychison
2011-01-25  0:24 ` [PATCH v1 1/6] Add oops notification chain Mike Waychison
2011-01-25  2:06   ` Greg KH
2011-01-25 20:01     ` Mike Waychison
2011-01-25 21:36       ` Jeff Garzik
2011-01-25 21:43         ` Aaron Durbin
2011-01-25 21:54           ` Jeff Garzik
2011-01-25 22:21             ` Aaron Durbin
2011-01-26  2:48               ` Greg KH
2011-01-26 21:50                 ` Mike Waychison
2011-01-25  0:24 ` [PATCH v1 2/6] Introduce CONFIG_GOOGLE_FIRMWARE Mike Waychison
2011-01-25  0:24 ` [PATCH v1 3/6] driver: Google EFI SMI Mike Waychison
2011-01-25  3:17   ` Greg KH
2011-01-25 23:12     ` Mike Waychison
2011-01-26  2:46       ` Greg KH
2011-01-26 23:58         ` Mike Waychison
2011-01-27  1:22           ` Mike Waychison
2011-01-27 23:41             ` Mike Waychison
2011-01-28  2:56               ` Greg KH
2011-02-20  4:44               ` Matt Domsch
2011-02-21 13:58                 ` Matthew Garrett
2011-01-27 10:43           ` Alan Cox
2011-01-27 19:22             ` Mike Waychison
2011-01-28  2:55               ` Greg KH
2011-01-28  2:59           ` Greg KH
2011-01-25  0:24 ` [PATCH v1 4/6] driver: Google Bootlog Mike Waychison
2011-01-25  0:49   ` Alan Cox
2011-01-25  1:38     ` Mike Waychison
2011-01-25  9:43       ` Alan Cox
2011-01-25  0:25 ` [PATCH v1 5/6] Allow prepending to the dmesg Mike Waychison
2011-01-25  1:01   ` Andrew Morton
2011-01-25  0:25 ` [PATCH v1 6/6] driver: Google Memory Console Mike Waychison
2011-01-25  2:00   ` Greg KH
2011-01-25  3:01 ` [PATCH v1 0/6] google firmware support Greg KH
2011-01-25 19:58   ` Mike Waychison
2011-01-26  2:47     ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110126024729.GC28283@kroah.com \
    --to=greg@kroah.com \
    --cc=adurbin@google.com \
    --cc=dlaurie@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=san@google.com \
    --cc=thockin@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.