public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Jim Ramsay <i.am@jimramsay.com>
To: linux-mtd@lists.infradead.org
Subject: Should MTD_WRITEABLE be split into MTD_WRITEABLE and MTD_ERASEABLE?
Date: Mon, 22 Sep 2008 15:03:32 -0400	[thread overview]
Message-ID: <20080922150332.57fb2252@altair.jimramsay.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

Currently, MTD partitions that do not begin and end exactly on an erase
sector boundary are forced to be read-only (The MTD_WRITEABLE flag is
forcibly removed).  I understand that this is required so that you
don't try to erase that partition and accidentally blow away other
information on other partitions that may also share the erase sector.

However, in the case of embedded systems, it can be very useful to
create a very small MTD partition for a simple write-once facility
(such as for capturing part of a log file or crash dump), and this
check makes such a partition impossible - Even if the code that
actually adds the partition is clever enough to properly erase that
area of flash before adding it.  There is no technical reason of which
I am aware that prevents normal mtd_write code from working on a small
non-erase-aligned partition if it has been previously erased.

So I would suggest that splitting MTD_WRITEABLE into two flags,
MTD_WRITEABLE and MTD_ERASEABLE would be a good idea.  The current
check for erase boundaries would then only remove MTD_ERASEABLE, whereas
MTD_WRITEABLE could still be removed via the mtd_partition.mask_flags
when required.

Would this have more side-effects than I currently understand?  Or would
it be a useful feature that may be considered for inclusion into MTD if
I were to write up a patch?

The other possibility, which is my current workaround, just adds a
special flag (MTD_UNALIGNED) which when found in
mtd_partition.mask_flags, skips the check erase boundary alignment
checks and allows these small partitions to be writeable. However, I'm
not sure what would happen if I tried to erase this small partition, so
I think splitting the WRITEABLE flag is a much more proper solution.

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

             reply	other threads:[~2008-09-22 19:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-22 19:03 Jim Ramsay [this message]
2008-09-23 15:27 ` Should MTD_WRITEABLE be split into MTD_WRITEABLE and MTD_ERASEABLE? 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=20080922150332.57fb2252@altair.jimramsay.com \
    --to=i.am@jimramsay.com \
    --cc=linux-mtd@lists.infradead.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