Hi,
Those were some seriously busy weeks and I only had limited time for the
fdisk rewrite thing. Despite my idleness, I've been toying with the
ideas of making some more tests for fdisk prior to more patches
submission, using the same logic as the current (only) test for doslabel
(ie. sequence of binary image md5's after executing an edit command),
except this time for other labels, checking at least basic things like
creation/deletion of partitions.
Unfortunately with other labels there's a major obstacle. In fact the
dos labels have the same obstacle: randomly generated partition table
ID. Every time one creates an empty dos label, the disk image is
(almost) unique. With dos labels, there's an advanced option (x,i,<new
id>) which allows setting the id explicitly working around this issue.
With the other labels, there is no such thing.
Also, the extreme user hostility of the interface makes me wonder if
someone ever uses fdisk to create anything else than dos labels. Since
each label basically has its own menu printing and handling functions,
most of the options are actually either duplicated or not supported by
some labels (which makes sense for some options, but not all of them).
Also, some options seem rather misplaced. For example to create an IRIX
label, one has to create a dos label first, go to advanced options and
there it is. No other advanced options contain it. Or basic, for that
matter. (In fact, I suspect some parts of the obscure label code being
dysfunctional and noone noticing anyway, because it is not really
practically usable.)
So back to the topic, more tests. Of course, one could always just check
the "relevant" parts of the binary images created by fdisk, but that's a
rather obscure way, as what parts are relevant strongly depends on the
label type, and may even depend on the contents of the partition table.
So making tests know which parts are relevant kind of smells like making
new fdisk to test old fdisk. Unless someone has an idea how to sanely
work around the issue with randomized parts of the image, without doing
major code changes to support tests, I'm feeling more and more like
skipping any tests of the other labels, and going straight for some
major changes of the code.
It's probably also worth mentioning that unit tests here make even less
sense, as the internal interfaces are just plain ugly, and most tests
for the current code would have to be rewritten from scratch, testing
virtually nothing in terms of regressions.
After some code unification, all of those tests could be definitely
easier to make, but before it, I don't know.
Zdenek
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
