All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: b35362@freescale.com, linux-mtd@lists.infradead.org,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 03/10] nandwrite: consolidate buffer usage
Date: Wed, 14 Sep 2011 14:22:11 -0400	[thread overview]
Message-ID: <CAN8TOE8JOLPeHn6m9cfQbisuBT2mJVeTAw6ONiF=pTKGSufgPg@mail.gmail.com> (raw)
In-Reply-To: <CAMjpGUc4WemgB6sWeChR3dp2mWsaSQUDKmKOfE=C9FBdzfuc1w@mail.gmail.com>

On Wed, Sep 14, 2011 at 1:15 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 16:00, Brian Norris wrote:
>> Instead of using two different output buffers for OOB data, let's just
>> use the same one for all output. This adds an extra memcpy, but it
>> simplifies some future work, so it's worth it.
>
> could it be done by pulling out the pointer ?  make oobbuf a "char *",
> rename existing oobbuf to like "char _oobbuf[]", and then assign
> oobbuf to the relevant buffer and assume it's always set ...

It could be done this way, but actually, this patch was not intended
to stand alone; it was a precursor to removing one of the buffers from
nandwrite.c, as done in patch 07/10:
   mtdutils: move OOB auto-layout into libmtd's mtd_write
>From the comment in patch 07:
   "This patch also cleans up a need for an extra OOB buffer in nandwrite."

So I'd actually recommend that Artem push this patch (patch 03) out of
'master' and into the 'brian' branch, then we can review the final
product there. In the end, I intended nandwrite to only have a single
buffer for OOB, instead of having a read buffer and an oob buffer. We
would simply pass our unmodified OOB data to mtd_write() and then to
the new MEMWRITE ioctl, where the kernel would do AUTO or PLACE
layouts for us depending on the mode we chose.

Of course, this is just the ideal approach; many kernels will not
support MEMWRITE yet, so they would fall back to the old code. That's
what patch 07 did; it cut out one buffer and moved the old layout code
into its own libmtd function, legacy_auto_oob_layout().
legacy_auto_oob_layout allocates its own buffer when needed; this part
is very inefficient (and actually has a memory leak now that I look at
it...) Perhaps the "legacy" handling should be reviewed a little more
to prevent too many trivial buffers and memcpy's.

If nothing else, I will at least need to send a v2 for patch 07 so we
free `tmp_buf' in `legacy_auto_oob_layout()'. But it'd be better just
to completely rework that function's buffers...

Brian

  reply	other threads:[~2011-09-14 18:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-31 20:00 [PATCH 00/10] nandwrite: cleanup, support ioctl(MEMWRITE) Brian Norris
2011-08-31 20:00 ` [PATCH 01/10] nandwrite: trivial variable move Brian Norris
2011-09-11 13:00   ` Artem Bityutskiy
2011-08-31 20:00 ` [PATCH 02/10] mtd-utils: update mtd-abi.h Brian Norris
2011-09-09 17:11   ` [PATCH v2 " Brian Norris
2011-08-31 20:00 ` [PATCH 03/10] nandwrite: consolidate buffer usage Brian Norris
2011-09-11 13:07   ` Artem Bityutskiy
2011-09-14  5:15   ` Mike Frysinger
2011-09-14 18:22     ` Brian Norris [this message]
2011-09-18  2:53       ` Mike Frysinger
2011-09-19 18:50         ` Brian Norris
2011-08-31 20:00 ` [PATCH 04/10] libmtd: modify `mtd_write' to cover OOB writes Brian Norris
2011-08-31 20:00 ` [PATCH 05/10] libmtd: support MEMWRITE ioctl Brian Norris
2011-08-31 20:00 ` [PATCH 06/10] nandwrite: merge `mtd_write_oob' and `mtd_write' calls Brian Norris
2011-08-31 20:00 ` [PATCH 07/10] mtdutils: move OOB auto-layout into libmtd's mtd_write Brian Norris
2011-08-31 20:00 ` [PATCH 08/10] nandwrite: kill `--raw' option Brian Norris
2011-08-31 20:00 ` [PATCH 09/10] nandwrite: re-implement `--autoplace' option Brian Norris
2011-08-31 20:00 ` [PATCH 10/10] nandwrite: use common.h "errmsg" functions Brian Norris
2011-09-11 13:06 ` [PATCH 00/10] nandwrite: cleanup, support ioctl(MEMWRITE) Artem Bityutskiy
2011-09-14  5:17 ` Mike Frysinger

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='CAN8TOE8JOLPeHn6m9cfQbisuBT2mJVeTAw6ONiF=pTKGSufgPg@mail.gmail.com' \
    --to=computersforpeace@gmail.com \
    --cc=b35362@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vapier.adi@gmail.com \
    /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.