Should MTD_WRITEABLE be split into MTD_WRITEABLE and MTD_ERASEABLE?

[Jim Ramsay]

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!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080922/b355db05/attachment.bin