On 05/12/2009 02:28 PM, Karel Zak wrote:
The code in fdisk is a small subset. In the ptread library we have to
support all possible labels -- this is not so difficult, because the
code already exists in Linux kernel (see fs/partitions/ directory),
partx(8) and libparted.
Kernel is where i started. But using the kernel code seemed rather
difficult to start with, not only because kernel only does
reading/parsing, also because some things are simply done differently
there. Of course, whether it'd be more work to use kernel code rather
than try to cleanup fdisk code, that is a question.
This is reason why I'd like to start with ptread rather than with
fdisk refactoring -- write ptread is relatively simple task. But I
don't have a strong opinion about it -- you can start with fdisk
refactoring of course. I'll be happy with arbitrary useful patch.
Refactoring is necessary either way, whether as a start of a "ptread"
library, or to be able to make it work with a similar library from
different source.
(Note that GNU Parted is again actively maintained. For example Jim
Meyering is working on parted now. But I have my doubts that we will
ever see libparted as a library that is useful for basic system
utils.)
If they're not willing to split libparted into PT handling lib and FS
handling lib, I totally share the opinion of its [non]usefulness for
simple tools like fdisk. And after seeing the parted code, I don't think
such a split would be easilly done, let alone the probable lack of
motivation to do it. I believe parted simply has its own solid place in
the tool hierarchy, definitely different one than that of fdisk.
The ideal solution is review all available PT parsers (at least the
code in Linux kernel, fdisk(s), partx and libparted). I expect some
differences and I don't believe there is an "ideal" implementation.
I'll go and check more of them. The kernel code may give a good overview
as it contains probably the most complete label set support.
BTW, the number of your regression tests for fdisk(s) is ZERO :-(
..which is directly proportional to the difficulty of writing any tests
for this mess. ;) I'll try to think of a way to throw in some tests. A
quick and simple idea: make *fdisk operate on file streams instead of
block devices, and create a large set of prepared MBR's for blackbox
testing (perform an operation, and check the result against the expected
result using a shell script). A big problem is faking all the ioctl
stuff (?). Unit tests should definitely be employed ONLY after the code
has at least some decent layout and API settled, if they're not to be
rewritten all the time.
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
