linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: David VomLehn <dvomlehn@cisco.com>
Cc: Daniel Walker <dwalker@mvista.com>, linux-embedded@vger.kernel.org
Subject: Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
Date: Tue, 12 Aug 2008 16:39:41 -0600	[thread overview]
Message-ID: <fa686aa40808121539pc02a645n908500844c698bca@mail.gmail.com> (raw)
In-Reply-To: <48A0CC8D.3050302@cisco.com>

On Mon, Aug 11, 2008 at 5:34 PM, David VomLehn <dvomlehn@cisco.com> wrote:
>
> Daniel Walker wrote:
>>
>> On Thu, 2008-08-07 at 19:20 -0700, David VomLehn wrote:
>>>
>>> Allow diversion of characters generated through printk so that they can
>>> be logged separately. The printk_time variables is made externally visible
>>> so that functions processing the diverted characters can parse off the
>>> time added if CONFIG_PRINTK_TIME is enabled.
>>
>>> +
>>>  static void emit_log_char(char c)
>>>  {
>>> +       emit_crash_char(c);
>>> +
>>>        LOG_BUF(log_end) = c;
>>
>> Isn't this duplicating the making of a custom console driver? I'm not a
>> console expect, but I think you could have a console driver which
>> catches this output and logs it..
>
> Yes, you could, but this seems *so much* more straight-forward. Another option I
> considered was changing things so that the first level interface would simply output
> a character, possibly also passing some sort of context pointer. Then whatever was
> called by that interface could call a console driver, if appropriate. Even though I
> think this is really a cleaner way to do this, it also involves many more changes
> than I think are warranted just to get this little piece of functionality.

I'm not thrilled with this patch.  It seems so much more straight
forward in your special case, but it comes at the expense of making
the code path more complex in every other case.

I would much rather see this be done using the existing console driver
interface.  The only possible reason I could see wanting to do things
this way is if you don't trust the console code to call your console
driver, which I think is a pretty unlikely case.

g.

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2008-08-12 22:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  2:20 [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging David VomLehn
2008-08-08 15:55 ` Daniel Walker
2008-08-08 16:05   ` Mike Frysinger
2008-08-08 16:17     ` Daniel Walker
2008-08-08 18:09       ` Mike Frysinger
2008-08-08 20:10         ` Daniel Walker
2008-08-08 20:13           ` Mike Frysinger
2008-08-08 20:47             ` Daniel Walker
2008-08-08 21:24               ` [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput " Haller, John H (John)
2008-08-08 22:01                 ` Daniel Walker
2008-08-11 23:34   ` [PATCH] [RFC] emit-crash-char: Allow diversion of printk output " David VomLehn
2008-08-12 22:39     ` Grant Likely [this message]
2008-08-13  1:30       ` David VomLehn
2008-08-13  2:12         ` Grant Likely
2008-08-13 17:56           ` David VomLehn
2008-08-13 19:02             ` Tim Bird
2008-08-13 20:27               ` David VomLehn

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=fa686aa40808121539pc02a645n908500844c698bca@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=dvomlehn@cisco.com \
    --cc=dwalker@mvista.com \
    --cc=linux-embedded@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).