[RFC v2] UBI: UBIVIS (aka checkpointing) support

[Artem Bityutskiy]

On Wed, 2012-05-09 at 19:38 +0200, Richard Weinberger wrote:
> The following patch set implements UBIVIS (checkpointing) support for
> UBI.

Hi Richard, I would like to complain about the names again. I though I
better give this feed back as soon as possible...

Firs of all, thanks for doing this, I will look closer, and I am very
keen of merging this stuff once we are sure its design is good, allows
for future extensions and is backward-compatible.

Then naming :-) We discussed checkpoints in this list long time ago I
think. If you ask a random UBI user what would be UBI with
checkpointing, I am sure most people would tell you that this would mean
an ability to checkpoint a volume at any point of time, then do
arbitrary volume changes (e.g., upgrade the system, re-flash it), and
then be able to return to any of the old checkpoints.

This name is rally reserved to semantics like that. Btrfs implements
checkpoints. UBIFS could, in theory do as well. And UBI could do in
theory - you just need a large pool of unused PEBs and then you do COW.

Please, do not use word "checkpoint" for what you do at all - this is
asking for troubles - people will be confused.

Also, I think this new feature should be always compiled in. I do not
think we need this ifdef forest at all. You can detect run-time the
on-flash format version.

How about calling this "summary" as in JFFS2, or fastmap/fmap ?

Sorry for being pedantic, but clear terminology is really important, I
think.

Also the naming logic and the internal layout should allow us to add
more features. E.g., if someone comes up with real journal.

So may be just naming your stuff UBI2, having terms like "UBI2 format",
would be the easiest? Then someone could make this to be UBI3. A
documentation section could describe what UBI2 is and how it is
different from UBI1 or just UBI.

Thanks!

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120510/6dcbfb75/attachment.sig>