Revert ubi-tools changes

Restore ubi tools to their "original" state, which means to
the state they were before I stareted cleaning them up.

Instead, create a "new-utils" subdirectory and move my work
there.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

1 files changed, 56 insertions, 0 deletions

diff --git a/ubi-utils/new-utils/README b/ubi-utils/new-utils/README
new file mode 100644
index 0000000..7113b69
--- /dev/null
+++ b/ubi-utils/new-utils/README
@@ -0,0 +1,56 @@
+This directory contains a new UBI toolchain which is intended to replace
+the old one. All the utilities start with "ubi-" to distinguish them from
+the old utilities. All support "-h" option which prints sufficient usage
+information. See the MTD web-site for more information.
+
+Motivation for new tool-chain.
+
+I was doing very active UBI development and had to add new features like
+dynamic UBI devices and auto-resize feature. Because of the mess in the
+the old tools I basically could not figure out how to upgrade them. In
+my humble oppinion, they are unmaintainable. The original authors did not
+show enthusiasm when I mailed them and asked to clean-up the tool-chain
+[1]. Thus, I re-implemented them, but I did borrow things from the old
+tool-chain and preserved copyrights and author names.
+
+I really did try to clean-up the old tool chain, but gave up (see git
+history for confirmation). So,
+
+1. I found the source codes very difficult to navigate and read, especially
+   those related to pdd, pfi, and bootenv. Try to do this yourself - they
+   are a puzzle.
+2. I foud the concept of PFI needlesly complecated - PFI file is nothing
+   else but the initial configuration .ini file + the contents of the
+   UBI volumes packed into one file, but with some changes of the .ini file's
+   format. The PFI file format is not very nice and it is difficult to parse,
+   especially because the PFI headers do not tell you data star and end for
+   each data chunk, and you have to do additional parsing.
+
+   So basically, you have .ini file + images, then you transfer this to pfi,
+   which does not add any other information. For .ini you have libraries
+   which may parse them, for pfi - not. Then you have to parse this pfi
+   which adds unneeded and complex code. This all needs lists, hashmaps,
+   and so on - for no reason.
+3. I found the command line options of the utilities to be inconsistent.
+   This is OK when you script your single task and do not touch it anymore.
+   But when you have to use the utilities while developing and testing,
+   It is difficult to remember their inconsistent options.
+4. I found it wrong to add development options to user utilities like
+   "broken update". End users should not see them.
+5. I did not find any consistent style and convention inside which
+   irritated me.
+6. I found it weird to introduce needless "logging infrastructure" instead
+   of just re-directing stdout and stderr to another file.
+7. I found the tool to be rather IBM-setup oriented. For example, the VID
+   header position was hard-coded. Some utilities were just weird, like
+   mkbootenv, which changed some ethernet addresses mentioned in a
+   configuration file.
+8. Finally, it was very difficult to realize what is pfi and pdd, what for,
+   why I need this transiant pfi file when I just want to create an UBI
+   image. There was zero documentation.
+
+And so on.
+
+Feb 19, 2008, Artem Bityutskiy.
+
+[1]. http://lists.infradead.org/pipermail/linux-mtd/2007-December/020134.html