All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	jwboyer@linux.vnet.ibm.com, grant.likely@secretlab.ca,
	jketreno@linux.intel.com
Subject: Re: [PATCH] lib/hexdump
Date: Wed, 2 May 2007 16:15:33 -0700	[thread overview]
Message-ID: <20070502161533.cbf38b4b.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070502160635.31dd91e6.akpm@linux-foundation.org>

On Wed, 2 May 2007 16:06:35 -0700 Andrew Morton wrote:

> On Wed, 02 May 2007 15:56:48 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > Andrew Morton wrote:
> > > On Wed, 2 May 2007 15:35:56 -0700
> > > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > 
> > >> From: Randy Dunlap <randy.dunlap@oracle.com>
> > >>
> > >> Based on ace_dump_mem() from Grant Likely for the Xilinx 
> > >> SystemACE CompactFlash interface.
> > >>
> > >> Add hex_dumper() to lib/hexdump.c and linux/kernel.h.
> > >>
> > >> This patch adds the function 'hex_dumper' which can be used to perform a 
> > >> hex + ASCII dump of data to syslog, in an easily viewable format, thus
> > >> providing a common text hex dump format.
> > >>
> > >> It does not provide a hexdump_to_buffer() function.
> > >> if someone needs that, we'll have to add it.
> > >>
> > >> Example usage:
> > >> 	hex_dumper(KERN_DEBUG, data, length);
> > >>
> > > 
> > > Fair enough.  This is the sort of thing one could easily overdesign ;)
> > 
> > The Intel version also returned the number of bytes printed.
> > and they had a hexdump_to_buffer() for sysfs output.
> > 
> 
> Yeah, that's where we get into creature feeping.  Really it should be
> passed the address of a function which performs the per-char output and
> which is passed a bunch of args so it can do its stuff.  But doing printk
> of a single char at a time is a bit inefficient and produces mangled output
> on SMP.  And then we don't know the length of the output and we'd like it
> dynamically allocated and on and on.
> 
> Ho hum.  Perhaps a middle ground is to implement hexdump-to-memory as the
> core function.  hex_dumper() becomes a simple wrapper around that.  (but
> how big is its buffer?  One line would be OK, I guess)

Yeah, I almost did it that way.  We'll see.

> > OK, that's one way to do it.  I'll wait a bit for other comments.
> 
> Good luck ;)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2007-05-02 23:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02 22:35 [PATCH] lib/hexdump Randy Dunlap
2007-05-02 22:45 ` Andrew Morton
2007-05-02 22:56   ` Randy Dunlap
2007-05-02 23:06     ` Andrew Morton
2007-05-02 23:15       ` Randy Dunlap [this message]
2007-05-04  0:49         ` [PATCH v2] lib/hexdump Randy Dunlap
2007-05-04  9:39           ` Pekka Enberg
2007-05-04 18:22             ` [PATCH v2] lib/hexdump update on feedback Randy Dunlap
2007-05-04 13:41           ` [PATCH v2] lib/hexdump Hugh Dickins
2007-05-03  7:01 ` [PATCH] lib/hexdump Jan Engelhardt
2007-05-03 16:26   ` Randy Dunlap

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=20070502161533.cbf38b4b.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jketreno@linux.intel.com \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=linux-kernel@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 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.