summaryrefslogtreecommitdiff
path: root/ubi-utils/new-utils/README
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-02-19 14:54:17 +0200
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2008-02-19 16:41:16 +0200
commit86dd9696d3a1acb036d65909d93d73455b8aed3a (patch)
tree9e8bb6797b3bebd0bf83ae1fab2151a6dfeafe6a /ubi-utils/new-utils/README
parentef644090223e5983ca2492850354c1390e3368d1 (diff)
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>
Diffstat (limited to 'ubi-utils/new-utils/README')
-rw-r--r--ubi-utils/new-utils/README56
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